ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Cohen" <SCo...@sportvision.com>
Subject Question about MacroDef vs antcall
Date Sat, 25 Oct 2003 16:18:04 GMT
The new ant features wiki

http://nagoya.apache.org/wiki/apachewiki.cgi?NewAntFeaturesInDetail/MacroDef

says:

"If you are using <antcall> as a macro substitute, you really should look into this
task. It is not only going to simplify your build files but also speed up your builds considerably
as you skip the huge overhead connected with <antcall>."

Re: the "huge overhead connected with <antcall>":

Does this also apply to calls made to other tasks via "depends"?  And if so, is a macrodef
callable via depends? (I don't see how.)

Here's where I am going with this.  I am working on a large project that is built up from
smaller projects.  Most of the smaller projects are usually (but not always) untouched, but
they are touched just often enough that it is important for the master build to always build
them.  However, most of the developers working on the project find the added delay of using
the master script intolerable, even if they run a subsidiary target that does not rebuild
everything.  Their "quick and dirty" script is much faster.  I am trying to wring extra performance
out of the master script so that the delays in using its subsidiary targets will not be intolerable.
 But if many targets must "depend" on an "assess" target that tests whether the build is in
"lite" mode
and use that in an "unless" clause to avoid doing something, if these calls are "outrageously
expensive", the gain from this sort of thing will be small.

Does ant 1.6 offer a way around this problem, or is there perhaps another way in ant 1.5 even?
 My general feeling on ant scripts up to now has been, you can write an excellent quick and
dirty script pretty easily or you can write a complicated system of build scripts, but it's
very hard to make one script that serves both goals.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message