harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Deakin <oliver.dea...@googlemail.com>
Subject Re: [classlib] Simplifying the ant files?
Date Fri, 16 Jun 2006 10:48:53 GMT
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).

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.

>
> 2) There is a similar issue at the module level and again I think we
> should move the build.xml file up one level.  (The API distinction at
> this level is already pretty clear.)
>   

Yup - wherever we decide to have them, it makes sense for the structure 
of the build
scripts at the modular level to match that at the global classlib level.

>
> 3) Currently the 'build' target automatically does a 'clean'.  I think
> this dependency should be removed and a new target - 'dist' perhaps? -
> should be created for doing non-incremental builds.
>
> [Geir has already fixed the first part of this since I started writing
> this.]
>   

Sounds reasonable.

>
> 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?

>
> 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?

>
> 6) Mikhail (IIRC?) modified a few of the module build files to use
> macros.  I like this idea (in fact one of my earlier abandoned JIRAs
> took it quite a bit further) because it helps to hide the less
> important details of what is going on away from the important ones -
> in the case of the modules leaving only differences between modules.
>
>
> 7) The init targets in each module build.xml don't really contribute
> anything to the build.  Does anyone really read the output they
> generate?
>   

I actually found myself removing the init echos from a module I was 
building the other day
because it was bugging me - I wouldn't miss these :)

>
> 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?

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?

>
> 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).

Regards,
Oliver


> Regards,
>  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
>
>
>   

-- 
Oliver Deakin
IBM United Kingdom Limited


---------------------------------------------------------------------
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


Mime
View raw message