harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [classlib] build file stuff
Date Fri, 30 Jun 2006 09:26:09 GMT

Matt, this sounds great to me.  Thanks!  I look forward to the JIRAs.

I had a couple of things I was still thinking I'd change (descriptions
in the top-level and module build.xml files was one of them).  I was
also wondering if it was better to use imports for the make/build-*.xml
files since these are not supposed to be called directly any more.

Aside: Does anyone still call these [make/build-*.xml] directly?  If so,
perhaps we need more top-level targets.

I'm quite busy anyway so I'll hold off on my changes until you've had a
good look at them.

Regards,
 Mark.



On 29 June 2006 at 8:56, Matt Benson <gudnabrsam@yahoo.com> 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


Mime
View raw message