ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject RE: Configure->Template->Build
Date Tue, 29 May 2001 15:24:27 GMT
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

>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.


| "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               |

View raw message