Refactoring JavaFX Builds & Sources

[David DeHaven]

>> In addition to code generation, we also build a ton of native code (gstreamer, webkit, prism, fonts, glass, image loading). So that has to fit into the build system. Building native code is SLOW, so being able to avoid it for "normal" developers, and being able to avoid native builds when nothing changed in the native code, is important.
> 
> Building native code may be slow in general, but building e.g. Glass takes under a minute. Of course I agree that if code hasn't changed, it shouldn't be re-built.

The first time, yes. Especially large modules like WebNode, GStreamer and all the JSL shaders. Subsequent builds are very fast, barring the overhead of ant itself (which is horrible, IMHO). Getting a more efficient build system in there will go a long ways.


> One more point: presently we can clone the repository and build just glass itself (which is very fast as I mentioned above). This is useful for quick testing, and also we have a Glass-only demo app that doesn't depend on FX, so we can work on Glass w/o even building the whole FX right now. Can we make the new build system support this kind of partial builds (at least for Glass)?

I've suggested using subrepos but I'm not sure if those will allow doing a partial clone and building only certain modules. That's probably the only advantage of using forest (other issues with forest aside…). It would also be highly beneficial if each module could contain it's own RCS history. The problem with using a single repository is that it gets more and more bloated over time, breaking it up into smaller pieces mitigates that bloat and allows people to decide which pieces they want to spend the time pulling. It currently takes me a better part of an hour to fully clone the workspace over VPN, and I have a fairly fast connection and a dedicated VPN router.

-DrD-