I plan to make some changes to the federated build. I'd like to fix use-cases like:
ant build-classlib assemble-stuff which currently don't work as you might expect because working_classlib/deploy only gets copied to target/hdk by indirectly being copied to working_vm/deploy during the build-vm phase. The fix is to have assemble-stuff take classlib content from working_classlib and only vm files from working_vm. Writing the above also reminds me how much I'd like to rename: working_classlib => classlib working_vm => drlvm working_jdktools => jdktools Does anyone object if I do this? One reason for changing working_vm to drlvm rather than just vm is to allow for the use of another vm (such as the IBM VME) in the federated build. Ideally, I'd like to create an ibmvm directory with a build.xml, svn:ignore and README to help support this use case. Does this seem reasonable? I'd like to change the names of the binary artifacts to remove the harmony.bits variable. The harmony.arch variable has values like x86 and x86_64 so appending -32 and -64 adds very little and is just going to get confusing/silly if/when we support ppc32-32, ppc64-64, etc. Most users understand architecture names perfectly well and those that don't almost certainly wont understand the harmony.bits numbers any better. I'd also like to remove common_resources as a separate svn checkout. It only contains six files and the bootstrap problem means that the federated build.xml has to duplicate much of the properties logic because they are required before common_resources is svn switched in to place. Copying the files to the federated build would avoid the bootstrapping problem and allow the duplication to be removed. There are lots more changes but that will do for now. Regards, Mark.
