At 02:24 PM 5/29/01 +0100, Jose Alberto Fernandez wrote: >With this *YOU ARE* adding if/case/condition* to ANT.
Not adding it to the build definition nor am I making ant a XML scripting language (The two things people object to). I am using existing language and tools and adapting ant to run them at an earlier stage. >Lets face it, if it is jakarta-ant defined and maintained, it is ANT. No idea what this is meant to mean? >The beauty of ANT is its simplicity which allows peoples to understand ANT's >files with only basic knowledge of ANT itself. exactly ... so are you are arguing for or against Configure here ? >This new language for autoConfig will break that, Nope. It will actually enforce it by keeping the core clean. Currently we are going down the ugly scripting road. There has been support for; * Complete logic evaluation - and/or/not/etc (via condition + available) * Various dynamic templating hacks to get around things (like anton, javaon etc) >I definetly do not want >to have 100 pages of the ANT documentation explaining how XSLT templates >work. Certaintly there are books dedicated to the subject that are fatter >than that, so it is not just a retorical statement. So don't use it. It is not you that this provided for. If you recall the most complaints ant receives is because it * is not a scripting language * doesn't scale well Generally it is the larger products that have this effect. I know I have about 17 almost identical build files scattered across a number of projects. It is an absolute pain to hand maintain these and they are mostly simple build environments (ie store jars in build location and require user to setup a whole bunch of vars manually). I am sure if you ask the build engineers who have to maintain medium to large sized products they will complain most loudly about the loops they have to jump through ;) >> As most committers agree that making ant a script language is >> a bad idea >> then we have a problem. Certain stages of build process need >> ad-hoc logic >> (aka scripting) - namely the first stage of detecting >> environment. So we >> either make people jump through loops (yuck), add scripting >> to ants core >> (yuck) or make it accessible through another stage (yea!). >> > >How is a pure Java autoConf going to solve this. I mean where are all this >configuration parameters for the different configurations comming from. Same place they come from in native version??? * location/presence of local libraries, compilers, features, build options, directorys etc Recall all the complaints about jakarta build practices from a while back. They generally include things like storing jars in CVS, disallowing customization etc. This is primarily because java has an immature development environment (compared to c/c++). I am hoping that real soon now things like ant/cjan/gump and outside initiatives (ie debians java standard dir layout for unix systems) will make developing with java more mature. And we will need a build system that will accomodate this. I hope it will be ant ;) You propose going down makes path by constantly adding features to ant for dynamic scripting/templating to get these features. Very few people are capable of doing this sort of thing within vanilla makefiles - not because the features are not there - but because it is not simple. However most people find make to complex and thus separate complexity out into layers (ie Configure/template/build using tools like autoconf/automake-imake/make etc). Smaller chunks make for easier understanding and a cleaner build process for most people. This is exactly what I propose - break a complex problem into smaller problems and tackle them each individually. Layering is a SOP in software engineering and I can't really understand your objection to it. >Aren't you just trying to add conditionals in desguise? exactly the opposite. It is adding conditionals/logic/scripting completely in the open and giving people facilities to use it that way instead of embedding it into their build description. >Can you give >examples of the kinds of real world issues that you think can only be solved >properly by autoConf? pick any of the requyests we have have had for last 12 months and we have rejected due to added complexity and 90% probability it is one of the use cases. Recent examples include * the need for per task failonerror (better solved with templating - which needs configure stage to run first). * anton/javaon/etc are all ugly hacks to get dynamic templating which should be done via Configure+templating (ie configure generates list of classes/directories while templating applies rule). * ever reoccuring if as tasks or as attributes of tasks (I think only accepted for antcall atm). >> So if you can think of a way to solve the problem then we throw away >> separate configure stage. If you can convince the committers >> that we don't >> need to support complex build environments then we can >> throwaway the stage. >> Otherwise I can not see any other alternative considering the >> goals of ant. >> > >Can you provide some realistic scenarios? see above or just think of any large complex build situation. Better to think of c dev as it is in many ways more mature an environment. >What is what you think is >impossible (or very unintuitive) in ANT (or ANT2's proposal). My current >thoughts about it is that people feel autoConf is needed and fill includes >and mutable properties are needed because we are use to MAKE and the >patterns developed over time for MAKE and we want to apply those same >patterns in ANT. I would argue that ANT has (or will develop) its own >patterns in which mutable variables, textual includes, and I think autoConf >are not needed. Again you haven't said why you don't think it is needed. You identify attributes of make rather than configure stage. Configure solves a different problem domain. I actually don't think that ant should allow mutable variables at all nor allow textual includes (neither encourage simplicity or good design) however they have nothing to do with Configure style systems. I am not sure you understand the role autoconf plays in native build systems. >This, of course, involves a paradigm shift of proportions I don't really >know. But I think this is a very important aspect of the ANT future success. >Like with any other programming tool, the success of maintainability and >expressibility relies on the patterns of best practice developed for them. exactly. And it is a well known fact that if complexity is broken down into smaller more easier to understand bits then the problem is instantly easier to tackle and maintain. >No one is saying every user will have to write their own system. I am saying >such things should be separate from ANT. ANT should be agnostic about it and >jakarta-ant should allow the rules of the "market-place" finally decide what >people like or not like to use. As long as ANT provides plugability, there >should be no reason for ANT to be in the bussiness of maintaining and/or >distributing XSLT, JPYTHON, or something else. Strawman arguement. No one said Ant would be maintaining or likely distributing any of these things (XSLT/JPYTHON/etc). I would much prefer to let the community decide which is the whol epoint of making it pluggable. However we need to prototype the system and I would have preferred it to be something the dev team is comfortable with. Cheers, Pete *-----------------------------------------------------* | "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 | *-----------------------------------------------------*
