ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <j_a_fernan...@yahoo.com>
Subject RE: Configure->Template->Build
Date Wed, 30 May 2001 00:02:32 GMT
> From: Peter Donald [mailto:donaldp@apache.org]
>
> 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.
>

Peter, my point here, is not whether the ANT core has this or that, my point
is what is it the user is writing and what kind of operations (and hence
semantics) are we providing to the users. So the fact that all the ifs,
loops and conditionals, produce an ANT file without ifs, loops, and
conditionals is mostly irrelevant. The fact is that you will be moving the
users from writing ANT buildfiles to writing ANT "template language" files.
And here we have all the same issues again but in another syntax.

> >Lets face it, if it is jakarta-ant defined and maintained, it is ANT.
>
> No idea what this is meant to mean?
>

If we are to promote some specific template language or technology, then it
will be named "ANTs template language" whether we like the label or not. And
we will receive the bugs and be asked for enhancements, etc, etc.

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

Against. Now tell me, how do I know if my templates or autoConfig are
generating the right ANT buildfile? Since everyting is happening internally
and on the fly, how do I know? We will have to provide tools for that
(preprocess only), etc, etc. Sounds like a need for cpp.

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

The user is not writing ANT buildfiles anymore, it is writing in the
autoConfig/template language. He will have to understand that language. If
ANT accepts that as its input, then we need to explain what it means.

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

As I said, in my previous message there is a paradigm shift required when
moving from Make like tools to ANT and we need to understand it better. I do
not think the solution is to provide that same crappy mechanisms Make did. I
think a large percentage of these requests is because of this.

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

Well, how do you feel about ANT2s proposed <projectref>. I guess your 17
files could just have something like:

<project name="mymodule" default="mydflt">
	<property name="thismodule" value="......."/>
	<projectref name="environement" file=".../environemnt.xml" >
	  <param name="sourcedir" value="." />
	  <param name="destdir" value="${thismodule}/lib" />
	</projectref>

	<!-- and then just add the user targets for easy to use -->

	<target name="mydflt" depends="environment->default" />
	<target name="compile" depends="environment->compile" />

</project>

Something like this, looks that can solve quite cleanly the issue of the 17
identical buildfiles.

> 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 ;)
>

And I think we are trying to respond in ANT2, the point is how the response
looks like.

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

So, are you going to provide things similar to <tasks> that know how to find
out about local variables (since "local" is OS dependent), that know about
file systems, compiler versions, etc? Or are they suppose to write all of
these by hand, for each platform?

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

But make does not embed autoconf inside. You can call autoconf from make but
it is not part of it. By the same token, you do not need to embed (i.e.,
adopt) a particular autoconf like into ANT.

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

I still think we do not need it. But even if we do, I disagree of forcing
everyone to use a particular language to do it.

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

These are not "real world" examples of why we need a configure tool. These
are the things people are suggesting to use to solve some problem we have
not properly defined. What I am asking is for examples which you think can
not be done cleanly without these new feature. Lets see if we can come up
with alternative solutions.

Notice, I am not suggesting ANT is complete as is, I know we need new
functionality, the question is what.

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

Well explain it to us. My understanding is that such systems where
originally developed to bridge the large disparity of UNIX file systems
layouts. The need was for something that new about AIX and Solarisad was
able to put the correct values in the makefile so my c program can find its
libraries and the compilers can find its switches (since every one has its
own thing). Now, are we trying to move ANT to support C and other languages
on that group? If that is not the main fucus of ANT, why should be change
its architecture to support them?

Can we achieve the same without it? I will say yes, because we can do the
same by just writing a <task>:

	<target name="prepare" >
	  <configure template="myConfigurationLanguageScript.cfg"
	 		buildfile="TheconfiguredBuildFile.xml" >
		<param ..../>
		<param ..../>
	  </configure>
	</target>

	<target name="compile" depends="prepare" >
	  <ant target="compile" file="TheConfiguredBuildFile.xml" />
	</target>

and so on. So as long as someone provides a <task> defining the autoconfig
tool and languaje, you can use it in ant as is. So that people writing in
this large build environments can do their own thing is so they want.

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

But, is XSLT, JPYTHON, etc, etc. really easier to understand? For example
how do you check in a OS independent way for which libraries are locally
available? Alot of the knowledge for how to do this things you get in
autoconf from its hardcoded executable and such. How, do you propose that to
happen in your case?

Jose Alberto

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


Mime
View raw message