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