harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib] Simplifying the ant files?
Date Fri, 16 Jun 2006 10:07:04 GMT
I just sent a note with a subset of these same concerns!

That's quite the laundry list ...

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

I just suggested the same thing, so yes.

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

The original intent was that there would be more variance in the native
code that had to be handled this way; if we are not seeing it then
great, simplify -- and we can address multi-platform concerns as we come
across them.

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

I really don't have a problem reading them, but whatever.  I thought
there were places where it was not just locations that were being
defined, but jar names etc?  I don't really mind either way.

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

As long as I can understand what is happening with a quick glance --
let's not get 'clever' ;-)

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

No.

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

Related to the build or in general :-p ?

I'd like to be able to download dependencies from the top-level script
too, so

svn co ...
cd ...
ant get-depends (or whatever)
ant             (builds everything)
ant test

and you are done.

Regards,
Tim

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

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