On Tue, Mar 9, 2010 at 4:38 PM, Mark Hindess <mark.hind...@googlemail.com> wrote: > > 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?
Yes this seems reasonable. I prefer concrete build systems that are simple and easily interpreted from just browsing the files. The 'working_' abstraction always seemed awkward and the value never came to fruition. > > > 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. Agreed. We should stick to the common conventions for arch names - x86, x86_64, IA32, IA64, ppc, ppc64, etc. > > > 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. Go for it. > > > There are lots more changes but that will do for now. > > Regards, > Mark. > > >
