harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@yahoo.com>
Subject Re: [classlib] build file stuff
Date Thu, 29 Jun 2006 20:04:27 GMT
--- Tim Ellison <t.p.ellison@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


Mime
View raw message