Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: 195.212.29.136 is neither permitted nor
 denied by domain of mark.hindess@googlemail.com)
Message-Id: <200606161151.k5GBpYTg028832@d06av02.portsmouth.uk.ibm.com>
From: Mark Hindess <mark.hindess@googlemail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] Simplifying the ant files? 
In-reply-to: Your message of "Fri, 16 Jun 2006 11:48:53 BST."
             <44928C95.6070307@googlemail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 16 Jun 2006 12:51:34 +0100


On 16 June 2006 at 11:48, Oliver Deakin <oliver.deakin@googlemail.com> wrote:
> Mark Hindess wrote:
> > There are a couple of things I'd like to "fix" about the build.xml
> > structure.  I'd be very interested in what other people think about
> > these issues.  In no particular order:
> >
> > 1) Currently when you look at the classlib checkout for the first time
> > the first think most people are going to do is look for a build.xml
> > file.  Well, we don't have one at the top level.  Fortunately 'make'
> > is an obvious place to look but then you find several .xml files.
> > Again fortunately build.xml is the obvious choice but the other files
> > 'build-java.xml' and 'build-test.xml' might be confusing ... the latter
> > more especially when you come to run the tests.  (Granted reading the
> > README helps.)
> >
> > I think we should move build.xml up to the top-level.
> >
> > It isn't the case right now, but we should aim to make this the only
> > ant file that developers need to invoke when building/testing at the
> > top-level.
> >   
> 
> Agreed. A while back I opened HARMONY-286 (which was never applied,
> and is likely wildly out of date by now) to create build-java and
> build-natives targets in the main build.xml - I was spurred on by the
> fact that the only way to compile only Java or only native code was
> to go and run those particular Ant scripts, and there were errors in
> the scripts that meant they couldn't be run standalone without some
> tweaking (which I believe have since been fixed).

I think compiling native/java is less of an issue now we don't "clean"?
What do you think?

> It would be nice to get to a point where a developer can rebuild/test
> any part of the classlib just by calling targets in the main
> build.xml.
>
> > An example of why this doesn't quite work right now is that I
> > sometimes use make/build-test.xml with arguments like "test-archive
> > gen-report" to just run the tests for the archive module.  Rather
> > than create test-archive, test-auth, etc in the top-level
> > build.xml I think we should us a variable so you can do "ant
> > -Dtest.module=luni test" rather than "ant test-luni gen-report".
> > Obviously the default if the variable is not set should be to test
> > every module.  This is not dissimilar to the test.case variable
> > usage in the module build.xml files.
> >
> > I'm sure others can think of more examples.  I think doing this
> > helps to make it clear which parts of the ant scripts are API - that
> > we should aim to support (and over time stabilise) - and which bits
> > are "internals" that might change.
>
>
> Perhaps we could also have the capability to build individual modules
> by specifying "-Dbuild.module=luni"? Obviously this would rely on you
> previously building the whole classlib (as the modular build would
> require its dependencies to already exist) or have an HDK installed
> somewhere.

Some might argue that this would be better achieved by moving to
the module level, but it could come out in the wash when fixing my
"test-luni gen-report" issue so I don't see any problem with supporting
this.

> > 4) Also at the module level, I think we should compress the two layers
> > of make/build.xml and make/common/build.xml.  For one thing it is very
> > confusing, that:
> >
> >   a) modules/auth/make/common/build.xml builds the platform-specific
> >      java code, and
> >
> >   b) modules/luni/make/platform seems to be related to what we've been
> >      calling native code not about platform-specific java code.
> >
> > It would be crazy to separate building of platform-specific and
> > platform-independent java code because we'll only have problems
> > handling dependencies and it would mean a lot of duplication.
> >
> > Even if we renamed 'platform' to native, I still don't think the
> > separate build.xml is needed since all it would ever do - in the near
> > future when we start moving the native code - is call straight out to
> > a makefile (or configure or whatever) so I don't think this extra
> > layer would add much.
> >   
> 
> Agreed - currently the extra Ant files under platform are of no use and 
> can safely be removed.
> IMHO they won't become useful any time soon since, as you say, all we do 
> to build native code
> is exec whichever make command. I dont think that justifies separate 
> platform specific scripts.
> 
> Perhaps we could have Ant scripts organised in a similar way to those at 
> the top level?
> i.e. the main build.xml is at the top level of the module. Then under 
> the module's make
> directory we have a build-java.xml, a build-native.xml and a 
> build-tests.xml, which the top
> level build.xml delegates all of the "real work" down to. As you 
> suggested above, the top level
> build.xml contains all the common targets that a developer might want to 
> use, such as build-native,
> clean-native etc.
> 
> Sound good?

I like as few layers of indirection as possible but agree that modules 
and top-level should be alike where possible.

> > 5) The module ant files use a properties file to define a bunch of
> > variables called:
> >
> >   hy.<module-name>.blah.blah
> >
> > Is anyone really attached to xml properties files?  Personally I find
> > it much easier to read text properties like:
> >
> >   hy.luni.src.main.java=src/main/java
> >   hy.luni.bin.main=bin/main
> >
> > than:
> >
> >   <hy>
> >     <luni>
> >       <src>
> >         <main>
> >           <java location="src/main/java" />
> >         </main>
> >       </src>
> >       <bin>
> >         <main location="bin/main" />
> >       </bin>
> >     </luni>
> >   </hy>
> >
> > [Aside: hy.luni.bin.main isn't used (correctly) any more anyway.]
> >   
> 
> These files can be a little bit unreadable - are you suggesting
> that we still have a separate properties file but it contains plain
> one-line properties instead of xml, or get rid of the separate
> properties file altogether and incorporate all the required properties
> into whichever build script they are appropriate to?

I was thinking still keeping a separate file.  There might be an issue 
with some "location" variables since you can't distinguish between
value and location properties in text files.  (At least I don't think so
but I could be wrong.)

> > 8) Running "ant -f make/build.xml" from a module sub-directory doesn't
> > actually clean the main compiled classes.  (I think this is pretty
> > important to getting consistent expected behaviour so I'm looking at
> > this right now and will fix it shortly unless anyone shouts.)
> >   
> 
> Do you mean the classes that are built under the
> <classlib_trunk>/build directory?  Since I've been doing work on
> modularisation recently, I've been thinking about where modules should
> build their classes when you run the module level build script.
>
> I was thinking about a developer who only had, say, luni checked out
> and an HDK to build against. He goes into the luni module and runs
> the main build.xml, but when this builds the Java code it tries to
> stick the classes into <module_dir>/../../build, which doesnt actually
> exist! I was wondering if maybe the default output dir for a modular
> java build should be <module_dir>/build, and for a global build it
> will be <classlib_trunk>/build?

We had things building to two places before it caused really confusion.
I think George would remember the details.

> So can I suggest that the modular build.xml defaults to building and
> cleaning its classes in a <module_dir>/build directory, but allow the
> location of the build directory to be overridden?

The first part is what I was suggesting but ... I think the overriding
needs thinking about a little more.  Specifically, I don't want someone
doing:

cd classlib
ant
cd modules/luni
ant

and having classes compiled to two different locations.  But if modules/
luni is your "top-level" then yes, building to ../../build is a little
odd. ;-)


> > Well, these are some of the things that are bothering me.  I suspect
> > others have other issues?
> >   
> 
> I also notice that the modular build.xml looks to open the
> properties file in the classlib/trunk/make directory by
> using a relative path from the location of the module i.e.
> <module_dir>/../../make/properties.xml.  If a developer only has
> that module checked out, then this relative location will not work -
> this is something that I guess can be approached if you rework the
> properties files (5).

I think there are a lot of issues when building with just one module
checked out.  I think we should fix the existing problems - but with
this issue in mind - and deal with this on a new thread.

-Mark.


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org