harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [build] Proposed changes
Date Wed, 10 Mar 2010 16:00:01 GMT

In message <f944d83d1003100658o1a083b6bu53dcb0923f16cc7d@mail.gmail.com>,
Alexey Varlamov writes:
> 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.
> >>
> >> [snip]
> >>
> >> 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 :))


I've been reluctant to remove the duplication because quite a lot of
people are working with just classlib checked out - typically using
the IBM VME - and having multiple trees to work this way is a little
awkward.  However, with these changes, I'd like to move towards a point
where you check out the federated build even when working with the IBM
VME.  Then we can get rid of the duplication.

Currently we have:

  federated/ [*]
    working_classlib/ [*]
                     modules/luni [*]
    working_vm/ [*]
    working_jdktools/ [?]
                     modules/samsa [?]

and support people building by checking out just the subdirectories
marked [*] (and maybe others such as those marked [?]) possibly using an

I think supporting all of these adds to the complexity of the build
system and also to the complexity for new developers.  I propose we
move towards a position of supporting working only at either the
federated level or at the module level (in which case you define hy.hdk
and deploy in to that tree).

Another thing that I think adds to the complexity and confusion of the
build system is the fact that we build and then copy in separate steps
rather than building in place.  I'd really like the "build-classlib"
target to build straight in to target/hdk and not require the additional
"assemble-stuff" target to be executed.  (As I mentioned even more
confusingly you have to do "build-vm" before "assemble-stuff" but I'm
going to fix that soon.)

Much of this has been discussed before but with no real progress.  Now,
I really want to make a concerted effort (with small steps) improve the
build system.

Comments welcome.


View raw message