harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Varlamov <alexey.v.varla...@gmail.com>
Subject Re: [build] Proposed changes
Date Wed, 10 Mar 2010 14:58:48 GMT
2010/3/10 Nathan Beyer <ndbeyer@apache.org>:
> 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 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.
>>
>>
>>
>

Mime
View raw message