On 2022-07-19, Roger Whitcomb wrote:
> I have a target description that has “${result.jar}” embedded
> within. But “ant -p” doesn’t do the substitution. I’m presuming that’s
> because the “-p” processing doesn’t evaluate condition or property
> tasks. But, should it? Would that be a huge code change?
Actually, properties are not expanded for any of the target attributes
at all. Well, if and unless are an exception in a way as properties are
expanded when the attributes are evaluated.
Properties get their value at runtime while executing tasks. Targets are
part of the static structure which is set up and configured before most
tasks are run. name, description and depends are not expected to change
at runtime so we never thought about making them dynamic in the sense
that their value may change after parsing the build file. For depends
this really would make things quite a bit more complex as the graph of
targets to execute then would change while it is being executed. name is
in the same category as it is what is used in depends.
It might be possible to expand properties for the description but that
would see the value of a property at the point in time when the build
file has been parsed, and maybe after all top-level tasks (those outside
of any target) have been executed. But given that expanding properties
for any of the other target attributes posed problems we never
implemented that.
There even is https://bz.apache.org/bugzilla/show_bug.cgi?id=38915 -
just sixteen years old :-). The report properly states we do execute top
level tasks before printing the project help, so the properties set
there would be available. And Peter has been right when he said
executing the top-level tasks during the parse phase would be "not
good", but we had to keep that for backwards compatibility reasons.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
For additional commands, e-mail: user-h...@ant.apache.org
