ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Vogel <pvo...@arsin.com>
Subject RE: Foreach task)
Date Mon, 11 Jun 2001 19:55:02 GMT
 
>> The *right* way would be for a couple of terms that are used anytime a

>> human describes a build process to find their way into the ant core:
>> 	foreach, if

>Hmm.  How about:
>
>'There should be no argument to any ant task which takes only a singular
>argument.  It should take a list of possibly one item, and promote a
>singular argument to a list of one if necessary.'

No!  That misses the point.  Suppose I want to run a process
(<exec>) on a series of files (<execOn>, perhaps) with a sequence
of arguments to those exec calls?

Let's face it, right now we have 3 CORE tasks that do *almost*
the same thing, just because we don't have a foreach:

<exec>
<execOn> (foreach file, <exec>)
<apply> (foreach file, <uptodate>, <exec if="uptodate">)

In other words, you anticipated a couple of common uses of 
foreach/if and hid them in an explosion of vocabulary words,
the difference between execOn and apply is so subtle, many 
people don't understand why there are two.

Suppose you are new to ant, and are reading a build.xml for
the first time, which is clearer to you:

<foreach property="tarball" type="files" basedir="${thirdparty}"
         includes="**/*.tar.gz">
    <exec executable="tar" dir="${thirdparty}"/>
        <arg line="xzf ${tarball}"/>
    </exec>
</foreach>

or:

<execOn executable="tar" dir="${thirdparty}"/>
    <fileset dir="${thirdparty}">
        <include name="**/*.tar.gz"/>
    </fileset>
    <arg line="xzf"/>
</execOn>

especially if I also see the use of <apply> in a 
similar context somewhere in the build.xml.

And what about cases where I don't want to run just one
executable, but want to perform a series of operations
on each file?  Or the cases where I don't want to <exec> 
but instead want to run, for example, <cccheckin> or <propertyfile>,
etc.

The point I'm trying to make is that the community seems bent
on *hacking* around the need for a <foreach> through an explosion
of tasks written in Java, obfuscating the fact that iteration across
a set of files or other parameters is a native part of the build
process.

You could literally eliminate some existing tasks that exist *only*
because of the lack of a decent <foreach>.  As I see it, foreach
would take either a list of files (provided by a fileset) or 
a list of strings and perform all tasks within it setting the value
of a property to an item from the list on each iteration.  If 
uptodate checking is needed, use the uptodate task within the
foreach.

It's clear, it's concise, and above all, it *describes* the build
process.

Extended to permit a <mapper> so that the underlying tasks
know not only the source file name but also another file name
based on the source name, the whole thing becomes even more
powerful and *descriptive*.

I just don't understand the fear with which this community looks
on <foreach> and <if>, they are key parts of describing a build
process.

-Peter

Mime
View raw message