You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mark Hindess <ma...@googlemail.com> on 2006/06/16 11:40:01 UTC
[classlib] Simplifying the ant files?
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
Re: [classlib] Simplifying the ant files?
Posted by Mikhail Loenko <ml...@gmail.com>.
Good stuff. I was also thinking about separating exclude list from modules'
build.xml.
Thanks,
Mikhail
---------------------------------------------------------------------
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
Re: [classlib] Simplifying the ant files?
Posted by Oliver Deakin <ol...@googlemail.com>.
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
Re: [classlib] Simplifying the ant files?
Posted by Tim Ellison <t....@gmail.com>.
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
Re: [classlib] Simplifying the ant files?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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