Guess I should probably chime in on the pro-Roger side as well. I'm wondering if the difference in perspective could be linked to those of us who are primarily build-engineer types. When I look for a build tool, I look for one that's going to be best for the situation at hand -- and, like Roger, I picked up on Ant primarily for its ability to handle java compiles (and other Java-oriented things, like jar'ing, etc.). I also look for a tool that's straightforward to use at the level that the developers need to use it -- ie., being able to just say '<buildtool>' for compiles, and easy modifying of the build-files for simple changes like adding/deleting source-files. Anything more complicated, they can either ask me to implement, or they can get into the tool deeper and work it out themselves -- but my experience has been that 99.9% of them don't want to get into it at that level. But I have to, so I also want a tool that's able to handle the complexities that are bound to pop up when dealing with all the things needed to do the full product builds/tests/installers/etc., and without having to do any (or at least not too many) "ugly contortions" (as Conor put it -- or "pretzled crud", as I put it, back when I was asking for a test-for-equality :)
I have a Swiss-Army knife. I don't think I've ever used more than two or three of the "blades" that are available with it (I can't imagine why anyone would ever need that little saw :) But having those options doesn't make it a Rube Goldberg device -- it's still a compact, well-designed, simple-to-use tool. And I think that's all people have been asking for -- to not have things dismissed out-of-hand simply because someone else doesn't have a need (at this point) to use them, but to look at whether what's being asked for can be added without over-complicating the tool itself. The test-for-equality mod that I have for the if/unless in my Ant doesn't interfere at all with using the if/unless as you "normally" would, it's maybe 5 or 6 lines of code, I only use it in one place in my whole build -- but having it available sure makes things easier for that place in the build where a test-for-equality was what I needed. Like the saw-blade, I don't know that I'd ever need an if/unless at the task level (can't think of a situation at the moment where I'd need it), but I think the criteria for deciding whether to make it available should be based on whether adding that capability will make Ant more useful to people who do see a need for it and whether it can be done without interfering either with the ease-of-use of the tool for those who don't or with the maintainability of the (source-code for the) tool itself. Diane --- Peter Vogel <[EMAIL PROTECTED]> wrote: > Heh! Well said Roger! The "we don't think its a good > idea, so Ant won't include it" is one of the reasons I > am hesitant to recommend Ant, despite the great leaps forward > that have happened since I started following ant at 1.1. > > I've been architecting builds for over a decade now, using > a variety of tools (Make, Cons, Perl wrapped around Make, ant, > etc.) and there are some fundamental capabilities that are > *necessary* to ensuring reproducible builds (which is the > whole point of CM) which Ant simply lacks, environment > encapsulation being one of them, a cleaner way of > doing conditionals being another. > > I'm a big proponent for a framework that is *simple* when > it can to be simple, and which makes complexity readable > when complexity is needed. The whole concept of "write a > task to do that" while cool for certain things, is fundamentally > broken for fundamental things like conditionals, etc. > Conditionals in build files are a fact of life in today's > cross-platform software systems, and even in some that aren't > cross platform, but which need to be configurable at > build time. > > That said, Ant is still a pretty cool tool, and I use it when > its appropriate, but I do get pretty annoyed by the "we're > smarter than you" attitude from many of the ant development > community that seems to consider anything that smacks of > "complexity" as evil. Go design an ant-based build of a > system consisting of 2M lines of code that produces 4 different > products with 90% of the components being shared across those > products and then tell me what features should or should not > be in the product. > > -Peter > -- > Peter A. Vogel > Manager+consultant, Configuration Management > Arsin Corporation, Professional Services > http://www.arsin.com > > > > > -----Original Message----- > > From: Roger Vaughn [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, May 16, 2001 7:42 AM > > To: [EMAIL PROTECTED] > > Subject: RE: if and unless attributes for all Tasks > > > > > > --- Jose Alberto Fernandez <[EMAIL PROTECTED]> > > wrote: > > > How understandable build files will be depend on our > > > choices. If I write > > > targets where every <task> has a different if/unless > > > condition, what does > > > that tell me about the readability of the build > > > file. It looks like > > > spaggetti code to me. I think the granularity is too > > > low. By having > > > if/unless at <target> level, you still can write > > > spaggetti code, but it will > > > make you think: "Do I really need to do it this > > > way?" And that is what makes > > > code understandable and maintainable, you have to > > > stop and think. > > > > You can obsfucate anything if you try. For instance, > > it is entirely possible to specify one task per > > target, and link them all up with dependencies. We > > don't do that because it's harder to understand. But > > it's certainly a simpler, more declarative model than > > multiple sequential tasks per target. > > > > I'm going to come out on the side of more features, > > more power, and more flexibility every single time. > > There is always some rube who is going to program > > himself into a real mess, but I don't think that's > > sufficient excuse to deny others of us flexible tools. > > FWIW, I feel exactly the same way about Java vs. C++, > > even though I do the majority of my work in Java these > > days. > > > > BTW, I'm still hoping for mutable properties (or > > perhaps a separate set of variables.) ;) Used > > *judiciously*, they can, in certain situations, > > simplify scripts quite a bit. Now, if someone goes > > wild and creates what you describe above, well then, > > that's his fault, not mine. This isn't a support > > organization, so I don't think protecting users from > > themselves should be the team's first concern. > > > > There's a certain arrogance here that's frequently > > annoying. The refrain "we don't think you should do > > that, so Ant won't include it" is heard pretty > > frequently. I understand reluctance to implement > > difficult or basis-shattering features (like > > templates), but for simple things, I just don't get > > it. Come on guys, be open to new ideas and different > > ways of doing things. If anyone finds this insulting, > > well, I'm sorry, but that's what I see. > > > > roger > > > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Auctions - buy the things you want at great prices > > http://auctions.yahoo.com/ > > ===== ([EMAIL PROTECTED]) __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
