ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Re: Expanding ${} constructs for all attributes
Date Wed, 13 Dec 2000 10:50:42 GMT
Peter Donald <donaldp@apache.org> wrote:

> At 11:00  13/12/00 +0100, Stefan Bodewig wrote:
>>Peter Donald <donaldp@apache.org> wrote:
>>
>>> While I won't block such a move I think it is possibly an example
>>> of flexability syndrome mentioned a few days ago. Can you think of
>>> any *good* use case for changing the value of either name or
>>> default attributes of project or name attribute of target?
>>
>>Not really. I do see valid use cases for setting project's basedir
>>based on user.home for example.
> 
> Could you expand on this and give an example of when it would be
> useful. ie When would the current mechanisms fail and how would this
> solve it. Also could it be solved by making basedir a special
> property. ie place "-Dbasedir=foo/" on command line.

Actually what you suggest (setting basedir on the command line) works
right now, this is what I recommend on ant-user as well. If you do so
you must not specify a basedir attribute for project at all.  The docs
say all attributes of project would be required, but Ant doesn't
really enforce this - quite the opposite.

It boils down to convenience, user.home has already been set by the
JVM, probably based on $HOME, so why should I have to specify it on
the command line again.

> 
>>> I see much much danger in evaluating depends attributes.
>>
>>If we were going to expand them at runtime that is, right. Actually
>>I was proposing to expand them at parser time - should have been
>>clearer.

When it comes to <project>, parser time and runtime are the same. We
need to know the basedir of a project when setting the dir attribute
of a <fileset> for example.

Evaluating the depends attribute at runtime would be a real pain as
you could not calculate the dependency graph up front and might realize
there is a cycle when you are half way through the build.

If we evaluate them at parser time, the problem would go away, but
that might make it less useful to those who want to expand properties
in the depends attribute, not sure.

>>> Besides the fact that has been asked for can you think of any good
>>> reasons to include it?
>>
>>Consistency.
> 
> good point. If we are going to make if/unless evaluated then it
> definetly becomes an issue - however they are evaluated at interpret
> time. Not sure thou.

You are right. Expanding the if/unless attributes at parser time
doesn't make much sense to those who ask for that feature.

Almost looks as if the only consistent way was to keep the current
behavior but change the documentation of project to better reflect the
truth.

Thank you for making me rethink the whole issue

Stefan

Mime
View raw message