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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
