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 Thu, 31 May 2001 13:19:07 GMT
At 01:38 PM 5/31/01 +0100, Jose Alberto Fernandez wrote:
>> The only other alternative is making ant a complete scripting
>> language. If
>> you can think of another alternative then I am all ears.
>> However as yet you
>> have failed to provide an alternative ;)
>I thought I did.

not yet.

>Well, since the task is not modifying the build file that it calling the
>task itself, I have no idea why are you talking about self-modifying code.

then I assume you have never programmed assembler then ;)

>Moreover, your proposal is doing in escence exactly the same thing, so I
>fail to see what is the hoopala about it.

But programming C++ and assembly is in "essence" doing the same thing.
Silly arguement.

>Just because I generate a file on disk, and you just generate the file in
>memory does not make much of a difference.

sure it does. It requires housekeeping, it introduces steps that do not
need to be present, it allows the build engineer to screw up something that
should be plug and play. It violates the basic UI principles.

>> Generating input for the current process is a painful think
>> to maintain and
>> debug. About the only people that still use it nowadays is
>> the lispers. But
>> then again even lispers don't generally do it except to create dynamic
>> command lists (which is usually dealth with via interfaces,
>> registries and
>> factories in modern environments).
>> Hiding this complexity from the user is soooo much better.
>What re you hiding, you are asking them to generate code in the form of an
>ANT XMLDOM (or something to that effect), my task is just writing that into
>a file. None of us is hidding anything.

eh? You sure you want to hold to that statement or do you want time to

>> That is appropriate to both uses (ie projectref as a ref and
>> as a "target
>> library"). All I see you using projectref as is as a xsl:include with
>> candied syntax - something I don't see any point in doing.
>It is not XML include. I am trying to move away from includes since I think
>they are the wrong abstraction to have. The differences are:
>(1) modularity, based on separate name spaces. This is a major point.
>Includes require you to avoid name collisions because everything is in the
>same namespace. It means you need to be aware of every property used on
>every include or you can have all kinds of extrange behaviours (very common
>problem in MAKE).

Thats one good point.

>(2) instantiation, based on parameters. The values assigned to properties on
>each instance can depend on the parameters you pass, which means that you
>can adapt the way the rules work, based on just a few parameters. More over,
>you can have multiple instances of the same project doing different things
>depending on the particular instantiation (you can never do that with

ouch - so now we including everything into core - templating and all.
Modularity was so passe anyways - screw engineering principles - you da man.

>I agree with you here. "include" is bad. But for the reasons I gave above, I
>think <projectref> can be shapped into something much better than include.
>As I said, it can be seen as a way to organize different aspects of a build
>into libraries. I do not see them to be nither painful to use, nor painful
>to implement (given the right datastructures) and they can give you a lot in
>terms of modularity. I do not think we have them just right, yet. There will
>be issues to be solved. 8-)

yup. Try thinking it through and attempting to implement a few practical
use cases. 

>> Considering that projectref will likely be used in more
>> advanced/larger
>> projects it seems logical that we should be going for more
>> maintainable
>> solution.
>I could say the same thing about asking people to write JPython or
>JavaScript ;-/

So you are saying that we should be using javascript/jython? Sounds good to

>> If you want these sort of hacks you have include,
>> anton/javaon etc which I
>> believe will fill all your needs. It is far better to make projectref
>> actually be a project reference rather than a library of
>> targets. Keep it
>> separate from templating so we can build maintainable projects.
>What I propose are HACKS while yours are .... interesting way to approach a

Nope they are based on well known software engineering principles. The same
ones that were "developed" in 60-70s and then "discovered" in late 90s post
the OO craze. It is unfortunate that most software engineers have no
perspective about history of their field. COP/SOC/IOC are not new
principles - they are as old as the hills. 

If you can't understand why separating out build process into components or
separating different stages of build is useful then it is no wonder that
you disagree with me. I assume you would also disagree with MS/Javas DPs

>> So your response is: Ant shouldn't allow medium to large maintainable
>> projects. Not a tenable position in my opinion ;)
>No, my response is that may be the way to structure it with ANT is

So describe it - convince me with logic and a practical example. Handwaving
and mumbling mumbo jumbo does no good on me.

>> >Yeap, ANT's aim for people to say what they want done, it is
>> not designed
>> >for the system to "discover" what to do.
>> Straw man arguement - who said it would?
>How is your configure suppose to know if rmic is needed or not on a
>particular module. For what I understand, your script will somehow find this
>out and adds that target in there. Isn't that what you want to do? Same for
>javacc, etc, etc.

I will say this yet again. You are STILL confusing templating with
configuring. Configure stage determins if "features" are present,
templating stage takes "template" and instantiates "instance" with rmic
target injected in compile target. Hopefully I won't have to explain this
for a fourth time ... or will I ?



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