ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Vogel <pvo...@arsin.com>
Subject RE: Properties and the <ant> tag
Date Sun, 10 Jun 2001 07:33:03 GMT
Of course, the right answer can be seen in Gnumake, the 
variable (property) assignment can be specified to override
external settings or to be explicitly subservient to external
settings.  I used it all the time, to set up "default" tool
locations which could then be overridden by a developer's
specific environment.  Assuming a developer installed everything
where they were told to in the documentation I provided, it was 
possible to build with a *completely* empty environment -- if not,
they had to set a documented environment variable to specify their
location for the tools installed in a non-standard place.

In ant I'd propose this:

<property name="foo" value="myfoo" unless="${foo}"/>

Makes the property setting subservient to upper levels, while:

<property name="foo" value="myfoo"/>

Makes the local property setting override the upper level settings.

Alternatively:

<property name="foo" value="myfoo" override="false"/>

<property name="foo" value="myfoo" override="true"/>

Where the default value of the override attribute would, IMHO be
"true".

-Peter

> -----Original Message-----
> From: Diane Holt [mailto:holtdl@yahoo.com]
> Sent: Thursday, May 24, 2001 2:40 PM
> To: ant-dev@jakarta.apache.org
> Subject: RE: Properties and the <ant> tag
> 
> 
> --- Jose Alberto Fernandez <j_a_fernandez@yahoo.com> wrote:
> > I have mentioned it before.
> 
> I think almost everyone has, at some point in time :)  And I 
> think pretty
> much everyone agrees (to a greater or lesser degree) that the way it's
> currently being done isn't ideal -- which is why it will be 
> changing for
> Ant2. 
> 
> > The current semantics makes absolute non-sense since it assumes that
> > every property in every biuldfile being build has the same meaning.
> 
> Granted -- but turn it around the other way: What about 
> properties that do
> have the same meaning? For example, attributes whose values 
> are given as a
> property. If I define the value for, say, the "debug" 
> attribute in <javac>
> with ${debug}, which is set to 'false' by default, and I want 
> to define it
> to 'true' for a particular run, I'd want that value to be in 
> effect for
> the <javac> tasks in all the sub-projects, not just the 
> top-level project.
> How would you see having sub-projects getting that value, if 
> they're not
> getting it from the parent project? (I'd like to see 
> something like "task
> templates", so you not only don't have to worry about things like the
> example above, but you also then don't have to replicate the 
> entire task
> everywhere you want to use it, and instead you'd just have that in one
> place, with only those attributes that differ [eg., the 
> included/excluded
> files] being specified in the tasks within the targets. But I 
> can't really
> propose that, since I'm not yet up-to-speed enough with Java 
> to be able to
> write the code for it, and it would be unfair to expect 
> someone else to
> just because I'd like to see it work that way.)
> 
> Diane
> 
> =====
> (holtdl@yahoo.com)
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Auctions - buy the things you want at great prices
> http://auctions.yahoo.com/
> 

Mime
View raw message