ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: <property allowoverrides="true" />
Date Wed, 15 May 2002 18:00:39 GMT

----- Original Message -----
From: "Dominique Devienne" <>
To: <>
Sent: Wednesday, May 15, 2002 8:48 AM
Subject: <property allowoverrides="true" />

> This subject about property immutability comes often enough that I'm going
> to add my $.02 about it ;-)
> (this post is prompted by today's 'Re: Re[4]: The old immutable properties
> trick' thread, and my weekend reading)
> Over a year ago, when I started playing around with ANT, having written
> makefiles only prior, I got frustrated by the immutability of properties,
> combined with relative inability of ANT to set properties conditionally. I
> also tried to replace my makefile to build a Win32 dll using ant tasks
> (superceded by antcontrib's cpp task I'm sure).

yeah, you should look at the ant-contrib task; they have done some nice
things there. You'll like it. I like their inheritance model too

> <xsl:choose> inside it. Why can't we do something similar with <property>
> ANT:
>   <property name="dll.extension" defaultvalue=".so">
>     <value os="Windows NT">.dll</value>
>   </property>
> and
>   <property name="lib.suffix">
>     <value if="debug">_g</value>
>     <value if="numega">_n</value>
>   </property>
> and also:

I can see a way to do this with <condition>. If we added a switch statement
like this, it shouldnt be in <property>, that is complex enough. (i.e. so
complex that people dont notice about <property env>, or even <property

>   <define name="_DEBUG"     if="debug" />
>   <define name="NDEBUG" unless="debug" />

> The property created is still immutable, but can take different values
> depending on other properties. Everything's controlled by properties (user
> ones, or builtin ones like 'os'), instead of targets with conditions.

I think you should start looking at mutant and myrmidion to see what their
story is vis-a-vis conditional execution of targets. Today targets are
conditional, most tasks hack failonerror in by hand, and some tasks do if
and unless.

It would be cleaner and more consistent for failonerror to be runtime
handled, the same for if and unless, maybe even for ifTrue and ifFalse tests
that eval strings to true/false, rather than set/unset.

> All this is really rough, and more like a brain dump that anything else,
> hopefully that could move the debate farther than 'property are immutable'
> and antcontrib's <if> can't make it into the code, etc...
> Or at least it demonstrate one *can* have override-able properties if one
> rolls once's own ;-) (OK, my impl is over a year old, wasn't tested with
> <antcall>, and certainly override-ability wasn't transferred to forked
> VMs...)

It'll still work today, but you will see warning messages on an override. If
a back door is in the public API, we have to leave it there precisely to
make sure that builds like yours still work.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message