It is not only with macrodef's that folk want "if/unless", but macrodef is a bit more obvious because of it's use as a replacement for <antcall> used as a sub-routine.
Using constructed property names is a good work-around for the lack of local properties. But it is a work-around, and there are some cases where true local properties would be more easily be used.
The <break> task is interesting. I am concerned however about how third party task containers would work with it.
Peter
Magesh Umasankar wrote:
From: Matt Benson <gudnabrsam () yahoo ! com> Date: 2004-06-23 15:02:54
I cringe at the thought of the number of "unique
properties" that could be floating about resulting
from this...
Is the user community complaining? The only issue
that seems to come up every now and then is lack of straight-forward support like if/unless/depends on macrodef and I'd like to see us address that. I haven't
seen a real-world use-case where the only way to
solve an issue is by using locals inside macrodef.
Hijacking the topic a bit...
Instead of adding if & unless attributes to macrodef, I suggest adding a new task <break> that can be placed
at arbitrary locations inside a task container to stop
further tasks in that container from executing. Cleaner
compared to if/then/else constructs and is not tied to macrodef alone.
<break> is smiliar to <fail> except that it re-routes control to the next task container instead of totally stopping the build process.
-Matt
Cheers, Magesh
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
