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:[EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
