ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject RE: Configure->Template->Build
Date Wed, 30 May 2001 03:38:50 GMT
At 01:02 AM 5/30/01 +0100, Jose Alberto Fernandez wrote:
>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.

Nope - only those who need the power will use it. Most people can live
within bounds of current day ant.

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

err ... people asking for enhancements to XSLT .... I don't think so. If we
create a new one then maybe or maybe if we use non-standard (ie Cocoons
SiLLY or Velocity) then perhaps but we can just redirect them to that list.

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

No idea what you are yammering about here. You will naturally have the
ability to run single stages at a a time. I assume that was a given.

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

The people that need this will most likely be fairly sophisticated. I
assume they will prefer that we point them to comprehensive documentation
rather than some slipshot description of our own creation. Personally I
much prefer to be able to read through documentation created by experts in
their domain who have professional writing experience rather than anything
created by an opensource community.


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

If they were identical yes but they keys is *mostly* identical. It is the
slight variations between them that becomes painful (besides which this
layout assumes java is immature - hopefully that will soon not be the case).

Because they have slight variations you end up with hariy build files or
else use per task if attributes or implement an if task (like what was
described recetly).

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

right - and as far as I can tell you seem to be denying the need for
scripting, or encouraging expanding ants core to add it. I propose the
standard practice of breaking down complex problems into multiple smaller
problems.

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

both.

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

no idea what this point means?

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

There will not be forced to use any language. We do need to create a
version though to test the ideas because it may turn out that we have a bad
design or the whole idea sucks or something similar. I am very anti taking
an academic design with out any real world practical uses.

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

You want an example - take your own example from above as one then ;)
Assume each project has slight variations and just try to write a clean
build file for it all ;)

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

Supporting c directly is irrelevent (though would be desirable).

>If that is not the main fucus of ANT, why should be change
>its architecture to support them?

Java is rapidly maturing. As I have already said we are starting to see
initiatives to standardize layout, packaging and distribution. When jdk1.5
hits the shelves there will possibilities of creating a Java OS (via
Isolate+Resources APIs). I would like to see ant in a position where it
could deal with this complexity.

This does mean dealing with different locations of tools/jars. ie
/usr/local/java/* for linux systems, /opt/java/* for some other unixes,
/opt/* for other unixes and presumably a java standard for other platforms
will eventually evolve. With tools like jjan/cjan on the horizon this is
becoming more of an issue.

When Java eventually gets opensourced we are going to have to deal with
initial fragmentation and reworking of librarys and even now testing for
presence of features/versions of APIs is necessary (see cocoon and their
effort to work around incompatible changes between Servlet2.2->2.3).

Currently we avoid many of these issues at apache by either including
jars/tools in CVS or requiring the user manually do "configure task" and
setup their own build.properties/ant.properties with results.

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

A while ago weren't you arguing against this? Yes most of the stuff could
be done with tasks in one way or another but the question is whether it
should be. 

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

For generic tests, tasks like available or new tasks will work. For other
ad-hoc tests they can hack at it in the host language. (BTW most knowledge
in autoconf isn't hardcoded but got from libraries of the most foul m4).

XSLT has nothing to do with configure stage either so I am not quite sure
why you keep including it.

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