ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Vogel <pvo...@arsin.com>
Subject RE: looping (RE: Foreach task)
Date Mon, 11 Jun 2001 18:08:44 GMT

 
> At 08:02 AM 6/11/01 -0400, asr@ufl.edu wrote:
> >So:  What is the essence of 'iteration' for the purpose of 
> this debate?
> 
> "iteration" for the purpose of this debate is something like <foreach
> .../>. Some people try to confuse the definition to serve an agenda or
> because of hangups from other build systems (ie make).

I certainly hope you're not accusing me of having hangups :-)  I think
that iteration is a pretty well understood concept: loop across a set of
values and perform some set of actions for each of those values...

> 
> >I define a set of input files Si, a set of corresponding 
> output files So, and
> >a process trans(Fi) by which an individual Fi may be 
> transformed to Fo, and
> >let ant figure out where it's necessary.
> >
> >Is that iteration?
> 
> nope - but good (GNU)make practices would implement this as iteration.

Hmm, I'm curious Peter, why you think good GNUmake practices would implement
the above-described scenario as iteration?  Perhaps you are the one who 
has make hangups?  Personally, in make I'd do this for the described
scenario:

Si = list.c of.c files.c
Fo = ${Si:%.c=%.o}

%.o: %.c
	Fi

Note the lack of iteration in anything other than the implicit iteration in
the translation of .c file names to .o file names.

In fact, to do iteration of the type I want a <foreach> in ant for using
make 
you have to step into the underlying shell language, or do some really gross
perl/python one liners, or you have to create an artificial generic target
and obfuscate the fact that iteration is happening:

TARBALLS = foo.tar.gz bar.tar.gz snafu.tar.gz
EXPLODES = $(TARBALLS:%.tar.gz=%.explode)
%.explode: %.tar.gz
	tar xzf $<
	touch $@

This is part of why many people hate make so much...

> 
> >I define a set of input files Si, a function up-to-date(Fi) 
> to tell if an
> >individual Fi has been processed, and a process trans(Fi) to 
> do the right
> >thing (perhaps untar, jar, whatever)
> >
> >Is that iteration?
> 
> nope - see above ;)

It's not exactly what I had in mind for iteration, but it is close.
I wasn't actually thinking of having foreach do up to date checking,
though I could see how it would be useful, for cases that actually do 
*appropriately* map to the make constructs I show above.  On the other
hand, there are cases (like tarball explosion) for which up to date checking
is inappropriate...

> 
> Both of the above would be best implemented as tasks. In Ant1 
> it is a PITA
> to do as there is little core support for writing such things 
> and keeping
> separate task libraries is also painful. In Ant2 we have 
> decided to build a
> "framework" so that implementing a task to do above will be trivial.

That's nice, but IMHO writing a new task for such things just leads to 
an inappropriate explosion of the build description vocabulary and actually
leads to inadvertent obfuscation of the build process and, worse yet, 
non-portability of skills.  If I work on project X and they have a bunch of
nice custom tasks to solve some common problems, then I move to project Y
and they *don't* have those tasks, or, worse yet, they have them but under
different names, my skills in ant need to be refreshed to learn the new 
vocabulary of the new project.  It's even worse if project X and project Y
are at different companies so I cannot re-create the tasks I was used to
from
project X from Project X's source...

> 
> However the usecase that ant needs is executing the same set 
> of tasks with
> different parameters. ie Repeat tasks t1 -> tn with different 
> values for A,
> B and C properties. It is really useful when you need to 
> repeate the set of
> operations over a large number of datasets (ie if you have 30 
> taglibs that
> all require same steps to generate compile and deploy etc).

Yep.

> 
> Essentially in this facility the foreach is acting as a 
> generic target with
> a (possibly dynamically generated) list of input parameters. 

I wouldn't call the foreach a "target" but I think you have
the general idea...

> The reason
> people ask for this is essentially because ant is not designed to have
> generic rules.  People have implemented them as hacks via 
> antcall/ant/dtd
> includes/etc but in general this increases cost of 
> maintaining project.

Indeed.   In fact, generic rules don't really follow the model of
"describing"
a build, while a "foreach" word does...

> 
> Since everyone seems to be an "expert" on this subject, it is 
> likely that
> no mechanism will be included in core. 

And this would be a sad mistake...

>You will have to go to other places
> (ie proposed taskdefs.org or perhaps sourceforge) to pick it up.

Again, leading to the very situation that the vocal people on this list
purport to want to avoid -- complexity, obfuscation, and confusion.  Put
core
functionality needed to accurately describe a build process into the core
of ant!

> 
> *-----------------------------------------------------*
> | "Faced with the choice between changing one's mind, |
> | and proving that there is no need to do so - almost |
> | everyone gets busy on the proof."                   |
> |              - John Kenneth Galbraith               |
> *-----------------------------------------------------*

Sad, but unbelievably true on this list :-)

-Peter

Mime
View raw message