--- Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > > Matt Benson wrote: > > --- Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > >> Andrey Chernyshev wrote: > > [SNIP] > >>> I guess the primary job of these scripts is to > >> setup the classpath > >>> correctly. > >>> We can get of them under assumption that > everyone > >> has a cpptasks > >>> (which is needed for native code compilation) > and > >> antcontrib packages > >>> installed with the Ant. > >> And as soon as we get rid of the need for > >> cpptasks.... ;) > >> > >> I wonder if we can add them to the classpath in > the > >> first ant-script we > >> run, and then have them avail for invoked > scripts. > >> > > > > Seriously, if the native build is switched to a > make > > approach, it wouldn't be impossible to remove the > ac > > dependency from what I can see in the drlvm > buildfile. > > Personally I would probably prefer the cpptasks > be > > used but grudgingly admit that actual C hackers > are > > probably more accustomed to make. ;) > > > > Beyond that, however, antcontrib is THE most often > > mentioned/recommended 3rd-party package on Ant's > user > > lists; > > Why don't you guys fold this into ant then?
ant-contrib contains programming concepts that are at odds with Ant's fundamental design. e.g. 1 <if> vs. <target depends if/unless>. e.g. 2 <for/foreach> vs. Java-implemented tasks using <fileset> or other types. <var> specifically exists to defeat Ant's concept of property immutability. For the most part one can get by without ant-contrib, but in a realistic world, sometimes it's just easiest to use it. Some of the other ant-contrib tasks just might be considered too specialized for Ant core. Ant's own distribution contains many things it shouldn't as it is; future versions will be looking to streamline by moving many of what are optional tasks today to antlibs that can be used optionally. > > > more than one of its developers are also Ant > > committers. I don't know that I see the harm in > > simply requiring that the user install antcontrib > (and > > cpptasks, while it is used). The user can simply > drop > > the jars into $ANT_HOME/lib (actually I don't set > > ANT_HOME but let the location of the invoker > script > > along my PATH pick it up, but that's a different > > story). > > Because it's annoying when you need to modify > standard tools just for > one project... > I guess that was kind of my point wrt ant-contrib being as commonly used as it is. You never know what other project will be relying on it; one might therefore consider it to be a "standard extension," as it were. > >On shared installations (with Ant >= 1.6), > > the user can install in ${user.home}/.ant/lib or > > supply the -lib option at the commandline. If the > > -lib option is chosen, that can be configured with > > ANT_ARGS . > > Oh, that's cool. Still, why don't you let me > augment ant's lib at > runtime from w/in the ant script? I would assume it > would be related to > initial parsing and recognition of elements in the > script, but some kind > of late-binding would be nifty... Ant's SVN HEAD contains a <classloader> task that can do some of these things. I'm not sure who uses it; I don't. It's been in HEAD and marked as experimental for some years now; it may well ship with 1.7 . I'll see what info I can dig up on this task. > > > My cygwin Harmony classpath build > > environment actually uses the -lib option to > include > > the ecj jar, for example. > > So there's no way to do a fork-like thing - let a > top ant script setup > the environment and then launch the script that does > the work? > You could, by forking Ant. Ant doesn't provide <ant fork="true">, however. One would have to configure the <java> task. The problem has been that nobody sees fit to keep track of the various cmdline options to forking Ant in code. This might actually make a decent antlib, however, as keeping such code in one isolated place would be easier. I'll have to keep this in mind... -Matt > geir > > > --------------------------------------------------------------------- > Terms of use : > http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __________________________________________________ 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]