harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <nbe...@kc.rr.com>
Subject RE: [classlib] build file stuff
Date Fri, 30 Jun 2006 22:19:53 GMT
Occasionally I use make/build-tests.xml to access the 'gen-reports' target.
I only do this when I run a test from within a single module, instead of a
full test run. Maybe there is a better or easier way.

-Nathan

> -----Original Message-----
> From: Mark Hindess [mailto:mark.hindess@googlemail.com]
> Sent: Friday, June 30, 2006 4:26 AM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [classlib] build file stuff
> 
> 
> 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


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