harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Hindess" <mark.hind...@googlemail.com>
Subject [classlib] Simplifying the ant files?
Date Fri, 16 Jun 2006 09:40:01 GMT

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.


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.

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


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?


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?

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


Mime
View raw message