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 08:53:06 GMT


> -----Original Message-----
> From: Jose Alberto Fernandez [mailto:j_a_fernandez@yahoo.com]
> Sent: Sunday, June 10, 2001 1:40 AM
> To: ant-dev@jakarta.apache.org
> Subject: RE: Properties and the <ant> tag
> 
> 
> > From: Peter Vogel [mailto:pvogel@arsin.com]
> >
> > 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.
> >
> 
> I proposed something very similar which I called default 
> value, a slightly
> modified version of my original post:
> 
>   <property name="foo" default="upperfoo" />
> 
> this give the local "foo" the value of "upperfoo" if defined, 
> otherwise it
> stays undefined. Properties from the caller are visible but 
> do not take
> precedence, unless specified as a <param> in the call. 

What does "upperfoo" represent?  A string?, the name of a variable?
something else?  That's why I didn't like it, it's not explicit about
what it is doing...

>So 
> your stuff avove
> is written as:
> 
>   <property name="foo" default="foo" />
>   <property name="foo" value="myfoo" />
> 
> 
> > 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".
> >
> 
> This one I do not like as much because it looks like the 
> callee can override no matter what, which raises the expecter 
> of mutable  properties, that I despise(sp?).

Despise is right, "spector" is what you mean :-)   I agree that,
in general, invisibly mutable properties are a bad idea, there
have been some interesting build debugging sessions where a 
deeply hidden makefile overrode something it shouldn't have (which
is why the developer hid it :-)  So I'll reverse my opinion of 
what the default value of "override" should be, but I won't reverse my
opinion that this syntax is more "transparent" than the one you propose.
I can, for example, detect all overrides in a tree with a single
find . -name build.xml -exec grep -l 'override="true"' {} \; command, in
your suggestion, I cannot do that...

-Peter
> 
> Jose Alberto
> 
> > -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