You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Matt Benson <gu...@yahoo.com> on 2006/06/29 17:56:12 UTC
[classlib] build file stuff
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
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.
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.
-Matt
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
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] build file stuff
Posted by Matt Benson <gu...@yahoo.com>.
--- Tim Ellison <t....@gmail.com> wrote:
> Matt Benson wrote:
[SNIP]
> > -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' ?
>
The particular example I was thinking of was in the
top-level build.xml, the awt-swing stuff is
conditionally built using its own target
"build-awt-swing" which is <antcall>ed from the
"build" target. In this case my assumption is that
this target exists only to provide the conditional
functionality via the target's if attribute (correct
me if I'm wrong Mark), but the concept remains: the
command line 'ant build-awt-swing' will execute just
that target. Perhaps "atomic" was a bad description;
I was only trying to communicate the idea of a target
that we want to be able to build by itself as opposed
to a target that has only been added for convenience.
Now, in the case of "build-awt-swing", again I am
inclined to believe it is actually the latter, but
whether "build-awt-swing" needs to be a separate
target from "build" would influence the decision of
what approach to take when eliminating the antcall.
> > 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).
>
It should be in direct proportion to the number of
antcalls currently taking place in a given target.
[SNIP]
> > 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?
This may be more clear after my having (attempted to,
anyway) explained the
"atomic-or-whatever-term-fits-better target" concept.
A macro is not a target in its own right; it is more
like a (in this case) locally defined task--a task
that happens to contain multiple other tasks.
Contrast preset which allows on-the-fly definition of
a single task with some (or all, but usually some) of
its attributes and child elements "preset". These are
complementary Ant 1.6 tools with which whole libraries
of custom tasks can be (and indeed have been) built.
If a given target is only ever called as an antcall,
it is most likely a macro masquerading as a target.
>
> > 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!
>
Thanks for the support.
-Matt
> 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
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
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] build file stuff
Posted by Tim Ellison <t....@gmail.com>.
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
Re: [classlib] build file stuff
Posted by Geir Magnusson Jr <ge...@pobox.com>.
I know Mark and Oliver are knee deep in this stuff to different
dimensions, so engage w/ them, but... sounds good to me :)
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.
> 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
> 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.
>
> 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.
>
> -Matt
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> 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