harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@yahoo.com>
Subject [classlib] build file stuff
Date Thu, 29 Jun 2006 15:56:12 GMT
Now that I've (finally, thanks Gregory!) got the
classlib built I'd like to start playing with the Ant
buildfiles to apply some of the practices encouraged
with modern Ant versions, but possibly lesser-known to
old-school (aka "learned Ant 1.5.x or earlier") users.
 The first thing I plan to do is remove <antcall>s
wherever possible (which should be everywhere).  <ant>
and <subant> run builds against other buildfiles; this
is sensible and the utility of it is obvious. 
<antcall> calls targets from a local (or imported)
buildfile, creating a new Project instance in the
process, a time- and memory-intensive process.  In Ant
< 1.6 <antcall>s could often be avoided by arranging
targets such that Ant's management of target depends
would take care of target interdependencies (the "Ant
way"); <antcall> remained useful for when some
parameterizable set of tasks was needed.  Ant 1.6 saw
the advent of <macrodef> which accomplished the
purpose of <antcall> in (damn it) a cooler fashion,
without creating a new Project context.  I joined Ant
right after the release of 1.6, and was myself daunted
by macros; I put off learning them until such time as
I couldn't claim I had anything else to do... but the
transition from antcalls to macros was painless.  The
"rightness" of this feature has never been challenged;
macros have become a new and shiny facet of the "Ant
way" IMHO.

That may have turned a little religious, but I took
the time to write it, so it stands.  :)  Anyway, my
point is that antcalls are evil and that a combination
of target restructuring and macros can remove all but
the very stubbornest of them (I can't even remember
offhand what kind of situation leaves no alternative).
 Here are the (IMO minimal) tradeoffs, for the sake of
allowing folk to voice any concerns:

-When you are calling a target with an <antcall>, but
you also want it to be available as an atomic target
of its own, that suggests the antcall should be
accomplished with target restructuring.  To some this
might make the build seem more complex.  In this

<target name="foo">
  <antcall target="bar" />
<target name="bar"><echo>bar</echo></target>

the "foo" target would become:

<target name="foo" depends="-foo,bar" />
<target name="-foo"><echo>foo</echo></target>

Now, I consider this "complication" of the buildfile
minimal, but I'm used to looking at such things.

aside: the minus target naming, as some users may
know, is an old Ant trick that prevents a target from
being called from the command line due to the fact
that it is interpreted as a switch by Ant main.  This
is of lesser value as Eclipse, as a handy IDE example,
does allow a user to directly run what is--by
convention only--considered an inner or private
target.  I could have named it "innerfoo" for example.
 Before we completely abandon the concept of inner
targets, let me mention that it might be a good idea
to always set descriptions on those targets intended
for user consumption, as in native-src/build.xml . 
This causes Ant's -p/-projecthelp to display only
these targets, hopefully making the task of using a
new buildfile less onerous for a newcomer.  In
contrast, classlib's top-level build.xml does not make
use of target descriptions.

When you are simply using a target as a container for
a group of tasks, and the target itself is not meant
for public consumption, that suggests the target would
be better defined as a macrodef.  And to be quite
honest, I'm having a hard time thinking of anything
negative to say about macrodefs.  They really don't
make your buildfile any more complicated or anything
else.... !  Oh, well!  :)

If anyone is still with me after this tome, my purpose
has been to elicit comment of any qualms anyone has,
particularly with regard to target/dependency
restructuring, before I start submitting JIRA issues
to remove <antcall>s.


Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

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

View raw message