harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib] build file stuff
Date Thu, 29 Jun 2006 19:18:14 GMT
Matt Benson wrote:
> 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.

That would be great.  I'm definitely in that old school.  I've learned
enough to get by / cause trouble but definitely interested in learning more.

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

Then show me the way so I can impress my friends ;-)

> 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

What do you mean by '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
> example:
> 
> <target name="foo">
>   <echo>foo</echo>
>   <antcall target="bar" />
> </target>
> <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.

Still with you so far (but I guess it gets more complicated).

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

That is ignorance/laziness/oversight rather than deliberate, speaking
for myself at least.

> 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!  :)

How is that different from the 'inner targets' you were talking about
before?

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

Go for it, that's the best way for us to learn.
And thank you!

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


Mime
View raw message