harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [classlib] Simplifying the ant files?
Date Fri, 16 Jun 2006 10:37:14 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.

+1, strongly

I tried this a while ago, and someone undid it :)

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

+1

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

Yes.  I think I was responsible for this, and this is a nice evolution.

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

I don't like "dist" - to me that's been traditionally reserved for
making a distribution (funny that...).

Maybe "rebuild"?

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

I lazily decided not to parse this, but I've been w/ you so far so I'm
sure it's fine.
> 
> 
> 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.]

+1

People who use ant are used to properties. and you can actually SEARCH
for things via

   grep -r "hy.luni.bin.main" *

(see previous rants about not being able to find the auto-gen-ed
properties of drlvm build...)

But please...  Please...  Please....

  s/hy/harmony/


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

+1

> 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?
> 
> 
> 8) Running "ant -f make/build.xml" from a module sub-directory doesn't
> actually clean the main compiled classes. 

As it shouldn't IMO..

> (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.)
> 
> 
> Well, these are some of the things that are bothering me.  I suspect
> others have other issues?


Yes.  It bugs me to no end that "build" isn't where we keep build stuff.
 It may simply be because I've hung around Jakarta and related too long,
but the convention I'm used to is "build" is where build stuff goes
(don't use "make") and "target" is the created directory where the build
churn happens.

This really is an aesthetic rather than technical argument, and so I've
kept my mouth shut until now, but I've decided to come out on this one
here... :)

geir

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

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