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/
