Well said! -Peter
--- Peter A. Vogel Manager, Configuration Management Arsin Corporation, Professional Services http://www.arsin.com > -----Original Message----- > From: Roger Vaughn [mailto:[EMAIL PROTECTED] > Sent: Friday, June 08, 2001 12:52 PM > To: [EMAIL PROTECTED] > Subject: Iteration (was Re: Configure->Template->Build) > > > I didn't intend my replies to become yet *another* > discussion about iteration - really. With that > said... > > --- [EMAIL PROTECTED] wrote: > > the poor maligned XSLT. We can iterate under the > > covers, but there's no > > reason to permit the buildfile writer to express > > them explicitly. > > I wholeheartedly disagree. That's extremely > shortsighted, and presumes that you know every build > problem every build writer is ever going to solve. > I'd like to short-circuit that point of view even more > than I'd like to get iteration into Ant. > > Iteration is not usually needed, true, but > *occasionally* it is. When it is needed, there is > just no clean substitute for it. > > Sometimes it is possible to write a task to "hide" the > iteration in Java, true. For one-off, single project > cases, which most of these cases are, however, this > often just isn't economical. > > Other times, it is *not* possible to write such as > task, at least cleanly, as in the case where you want > to execute several existing tasks per iteration. You > could explicitly call each of these tasks from your > new task, but then you're beginning to express your > build directly in Java, and you lose the > maintainability and focus that we use tools like Ant > for in the first place. (Note, this will not be as > much of a restriction when nested tasks are > introduced.) > > The last point relates also to a major beef I had with > the so-called iteration (the ! operator, I think) in > nmake - it iterated, yes, but only over one command at > a time. It would not let you iterate over a whole > target - i.e. a set of commands. > > > Think MAKE; You express transformations and > > 'iterate' by implication when foo > > depends on foo.o, bar.o, and baz.o. The syntactic > > difference in ANT, from my > > possibly ignorant perspective, is that you > > conventionally express dependencies > > between tasks, not between software products. > > In *basic* use, yes. There are still cases where the > default mechanisms cannot handle what the build writer > needs to accomplish. I occasionally needed explicit > iteration in make, and I occasionally need it in Ant. > > It is entirely possible to do without iteration - by > unrolling loops into their separate passes (i.e. write > a separate target for each pass through the > iteration). This is effectively what any > preprocessing step (XSLT, etc.) does. Prepocessing is > a bane to some people, however, and maintaining > unrolled loops by hand is a nightmare (eg. make sure > you make the exact same change in "n" different places > - and don't forget to change the file names in the > process!) > > Note that I am careful in my usage of the word > iteration. I think this is all that is needed - > executing a set of tasks (or a target) for each member > of a set. I don't think general loops (while, for, > etc.) are needed, but then, by my own arguments, I > can't anticipate every build writer's needs. > > > Our iteration is under the covers (IMHO) for only > > one reason: javac does it. > > Not so, not at all. Iteration is there because it's a > central and essential property of any build. Your > basic build cycle is "perform this set of operations > for each one of these files". In other words, > iteration. For javac, this is interpreted as "produce > a class file for each Java source file." For the copy > task, it is "perform a copy to that location for each > file in this location." > > The built-in tasks cover our most common iteration > needs, but not all of them. > > Try this argument on for size - iteration is a very > common build operation, perhaps the most common. Many > Ant tasks incorporate iteration inherently. For > operations not covered by existing tasks, it is > possible to write new tasks, also incorporating > iteration. However, project-specific tasks tend to > be, by their very nature, non-reusable. But they > incorporate reusable building blocks - like iteration. > So, since iteration itself *is* reusable, would it > not make sense to make a task out of it? > > And thus the "unofficial" foreach task was born. > > > This permits us to shove under the covers much of > > the complexity explicitly > > expressed in MAKE. This is shift is necessary: We'd > > all die of old age before > > completing any project if we had to run a separate > > instance of javac for each > > .java -> .class transformation we wanted to do. > > True, but you know what? There is absolutely nothing > preventing a build writer from writing such an Ant > file today - explicitly listing each Java file in an > individual javac task. We cannot be responsible for > some individuals failing to understand the basic > concepts. And like Diane, I almost always believe the > fault lies in the user, not the tool. Only when the > failure to understand is epidemic can you blame the > tool. > > > To accomplish the goals you desire, we could permit > > the expression of the > > make-like .java.class recipie, and some sort of > > inverted up-to-date target, > > which asserts that for each .foo in <source> there > > should be a .bar in > > <dest>, which should be up-to-date, otherwise run > > whatever-thingy on the > > individual .foo file. > > That's not necessarily a bad idea. It would most > likely be far cleaner than the current uptodate task. > The idea is far too limited, however, as it only > matches file extensions, and doesn't handle cases like > copying a file to another directory (which admittedly, > <copy> already does.) This limitation was a major > drawback in make. > > Similarly, it does not answer the need for iteration - > at least not 100%. It will cover *some* iteration > cases, but not all. Some iteration cases cannot be > determined by filenames or extensions, and need more > general - i.e. explicit - mechanisms. > > > This idiom would permit the expression of some > > heinously bad java compilation > > Again, we can't be responsible for a poor > understanding of the tool. It is already possible to > write horrible builds today. > > > targets. It would also permit the expression of the > > ideas the > > iterator-boosters desire. > > Again, not so. Target-source matching is not > iteration, and only solves a subset of such problems. > > The Ant authors-to-date have done a fabulous job of > limiting the need to specify iterations, and > conditionals, and file lists, and such things as we > used to have to contend with in make. However, they > can't anticipate the needs of every build, nor should > they be concerned with making Ant answer > higher-granularity problems - which often need > iteration and conditionals themselves. So, even > though Ant has successfully shielded us from most > cases where we need iteration, it has not entirely > eliminated that need. > > roger > > > __________________________________________________ > Do You Yahoo!? > Get personalized email addresses from Yahoo! Mail - only $35 > a year! http://personal.mail.yahoo.com/ >
