harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Beyer <ndbe...@apache.org>
Subject Re: [build] Proposed changes
Date Wed, 10 Mar 2010 00:24:46 GMT
On Tue, Mar 9, 2010 at 4:38 PM, Mark Hindess
<mark.hindess@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.
>
>
>

Mime
View raw message