2010/3/10 Nathan Beyer <ndbe...@apache.org>: > 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 also agree this is quite reasonable. But AFAIU only names are to be changed, not the layout? > >> >> >> 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. Indeed. > >> >> >> 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. Sounds good. (Will not tease about a lot more duplication in classlib this time :)) Regards, Alexey > > Go for it. > >> >> >> There are lots more changes but that will do for now. >> >> Regards, >> Mark. >> >> >> >
