Gert Driesen wrote:
----- Original Message ----- From: "Ian MacLean" <[EMAIL PROTECTED]>I agree with some - but not most. The value of the "if" attribute could be any possible expression. In fact the example that prompted this discussion was:
yes and as I pointed out - that can be done with:
<target name="foo" depends="foo-test" > <if test="${foo-exists}" > <do-foo /> </if> </target>
ie the dependencies set the value of foo-exists.
Yes, ofcourse.
fair point - I guess everyone has just worked around it up till now.If your first use-case is that common, then how come it has taken several years for this to become an issue ? ;-)
Yeah, could very well be. But I think you must agree that in some (most?) circumstances, other targets (that determine whether a given target should be executed) should get executed first (and set some property indicating whether the "build" target should be executed).
<target name="install-windows" depends="userdoc" if="${platform::is-win32()}">
where the result of iswin32() certainly isn't determined by running userdoc.
The major point I'm making is that this scenario is catered for by the nested <if> tag but the "stop this targets and all its dependencies" use-case which is the logical behaviour of the "if" attribute on target simply isn't possible with the current implementation - short of putting the condition on every target in the dependency chain. The proposed behaviour makes one use-case a little more cumbersome while enabling another that you agree is a useful one and at the same time reducing the overall "suprisingness" of the behaviour. I think thats a reasonable compromise.
You can document until the cows come home and someone eyeballing a new build script ( even an experienced nant user ) is still likely to assume that if="false" means skip the dependencies too. They may kick themselves and say "oh thats right its that weird target behaviour - let me go check the docs" but the point is in an ideal world they shouldn't have to.
sure - so leave it as a dependency and test for "is-uptodate" inside the build target. I agree its not as clean as using the "if" attribute but not much less clean - see my previous point.eg. how can I determine whether a "build" target should be executed, if the "is-uptodate" target is not executed first ? I think it would be pretty common to consider the "is-uptodate" as a dependency.
Ian
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Nant-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-users