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 02:59:35 GMT
At 03:56 PM 5/28/01 +0100, Jose Alberto Fernandez wrote:
>I got to say, I am very -1 on going the way of make and getting on the
>bussiness of an autoConfig sort of way of solving problems. I do not see the
>need for that.

You have said that a couple of times but never given any reasons. Can you
give some reasons.

Without this we will require that ant include if/case/condition/* style
tasks that are a declared non-goal. Simply because we need the flexability.
I have already had to fight often enough with some of ants rules that it
gets painful for large projects. 

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

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.

>Templates are a different matter, but I see them more as a mechanism for
>users to define preferences for tasks and for them to define their own high
>level tasks as composition of ANT's low level tasks.

template come after configuration because many templates require autoconf
variables (ie list of directories or presence of feature Y).
>I see the ability to write cryptic files that are only 3 lines long and from
>that produce a 50 pages long ANT file, to be king of outside ANTs goals.
>Now providing a hook or something for those who really want to go that way,
>well I may be convinced of that, but as such we shouldn't be in the
>bussiness of deciding what technologies they should or they should not use.
>They should be on their own on that.

thats ludicrous. Imagine if every user of make had to make up their own
version of automake/imake/autoconf/whatever. There is already too many
choices in that area. Hopefully we will recomend and support one method but
if peeps want to do it another way then that is also fine.

>The mechanism should be similar to that of the listeners. The hook should
>implement some  interface, in which we pass the input stream of the
>buildfile and and a the SAX ContentHandler needed by project helper. It is
>upto the user class to produce a stream of SAX events corresponding to the
>ANT pseudo DTD. We may give access also to the list of args in main so the
>tool can access its own additional options. That should be all.
>	public interface AntPreprocessor
>	{
>	  void preProcess(InputStream inbuild, String[] options, ContentHandler
>	  // This second one is to be able to compose preprocessors
>	  ContentHandler getProcessor(String[] options, ContentHandler out);
>	}

>The idea with the second one is that you can use it for chaining them.
>Notice that the first does not even require for the input to be XML, it just
>needs to generate SAX events at the end of the day.

similar to my idea of stacking them.


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