Do FlexBuilder and MXMLC Really Feature Incremental Compilation?

I use FlexBuilder in my work, and, overall, it's a decent tool. Eclipse gets a lot of points for being free; Flex SDK gets a lot of points for being free. FlexBuilder doesn't get points because it's basically the above two items glued together along with a GUI builder, and it costs real cash.

Wait, I'm off track already. The price isn't the issue for me. Rather, I want to know why FlexBuilder doesn't feature incremental compilation.

Hold up again, actually, I guess I want to know how Adobe defines incremental compilation since they insist that it is present and switched on by default in FlexBuilder.

Now, if I make any change (even spacing) to any code file -- or even a non-compiled file, like some html or JavaScript that happens to be hanging out in the html-template folder -- FlexBuilder rebuilds my entire project. And it's a big project, so, the job even on a 3.6GHz box means a chance to catch up on RSS or grab more coffee.

Interesting take on incremental compilation. See, I thought the whole idea was to allow compilation of some, ah, compilation unit -- say a file, or a class -- into an intermediate format which would then be linked, stitched or, in the case of Java .class files, just ZIPped into a final form.

Besides allowing compilation in parallel, this design allows for an easy way to only recompile the units that have changed: just compare the date on the intermediate output file to the date on the source file. If the source file has changed later, then recompile it. It does not appear that this is how the tool is behaving.

Perhaps this logic is already built into FlexBuilder -- mxmlc, really, since that's the compiler -- and the minutes of build time are spent on linking everything into a SWF. Since Adobe revs Flash player regularly, and many movies are compiled with new features to target only the new player, it should be possible to update the SWF format a bit in the next go-around, so that linking doesn't take egregiously long.

Apparently, at MAX this year, Adobe has started referring to the Flash "platform" -- meaning all of the related tools and tech involved around the runtime. Fair enough, it is a robust ecosystem. But "platform" kind of implies that the tools support writing real -- and big -- applications, not just a clone of Monkey Ball or another custom video player for MySpace pages.

Does LLVM Mean An Alternative to Objective-C is in the Works?

The LLVM project has popped up on the radar a bunch of times lately. There's a variety of speculation about why the sudden interest.

I'll throw my hat in and suggest that Apple is thinking seriously about a full-service alternative to Objective-C for programming against the native OS X (Cocoa) API.

Objective-C hasn't spread as a general use language on other platforms, and Apple is showing a higher level of interest in expanding its ISV/developer base.

While other language bindings have been promised or offered over the years, none have been developed or maintained to the point that they are a realistic equivalent/alternative to ObjC. For example, according to an Apple insider I spoke with, it turned out that, under the hood -- at the level of linking, marshaling, etc. -- the cost of the incompatibilities with Java just got to be too great to try and keep it as a first-class environment next to ObjC.

It would seem that LLVM could open up a lot of doors here.

If, as reported, the Xcode environment hooks in with LLVM/GCC, then there is a natural integration point introduced at the intermediate representation (IR) level.

It may not be trivial -- LLVM is designed to be lower-level than, say Microsoft's CLR. The CLR, together with the CTS (common type system) and various other infrastructure and requirements, created a level of guaranteed interoperability between any two .Net languages ... somewhat different from the purpose of LLVM, which appears to be more about the ability to rigorously transform and optimize code in a hardware independent manner.

In this sense it may be about helping with Apple's parallelization work as well as cross-compilation for GPUs or PowerPC. Still, at the end of the day, there are libraries to be called into and data to be passed. And having a big multi-language abstraction in the middle would seem to make it a lot easier to massage the call patterns of other languages so that they play nice with ObjC system libraries.

Oh, and check this out: it's fun and interactive: you can try it in your browser and see the IR right now!