> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Ian MacLean > Sent: vrijdag 3 december 2004 9:29 > To: Gert Driesen > Cc: 'Troy Laurin'; 'J. Christopher Six'; > [EMAIL PROTECTED] > Subject: Re: [Nant-users] Re: Segfault during compilation > with mono on Linux > > Gert Driesen wrote: > > >>>This is a legacy of Ant not having expressions or an if > >>> > >>> > >>statement, so > >> > >> > >>>the only way to conditionally perform tasks was via this > depends/if > >>>mechanism: > >>> > >>><target name="foo" depends="foo-test" if="${foo-exists}"> > >>> <do-foo /> > >>></target> > >>><target name="foo-test"> > >>> <available file="foo.txt" property="foo-exists" /> > >>></target> > >>> > >>> > >>> > >>Since NAnt now does have expressions then that behaviour > >>doesn't make as > >>much sense. You can achieve the same thing by putting the if > >>test inside > >>the target. However with the current behaviour you *can't* > >>prevent both > >>a target and its dependencies from being executed just by > >>using the "if" > >>attribute. This seems like one case where diverging from Ants > >>behaviour > >>might not be a bad thing. Certainly the current behaviour > >>violates the > >>"principle of least suprise". > >> > >> > > > >I understand, but it does make sense that dependencies can > have influence on > >whether or not the target should be executed. > > > > > they can anyway : > > <target name="foo" depends="foo-test" > > <if test="${foo-exists}" > > <do-foo /> > </if> > </target>
Ofcourse, but I prefer having the condition on the target (when possible). > > however right now you *can't* stop a target *and* all its > dependencies > from being run by using the if attribute - and that seems > like a big > functionality hole. Yeah, I know ... > > I think the "stop this target and all its dependencies from running" > use-case is a more common one than the: > > "stop only this target but let all its dependencies execute" one. If you put it like that yes, but another common use-case is : "execute a target, but have its dependencies decide whether tasks in that target should indeed be executed" If your first use-case is that common, then how come it has taken several years for this to become an issue ? ;-) > > >Compatibility with Ant has never been a goal by itself, but > we need very > >strong arguments if we intend to break compatibility with > Ant (in one of the > >few where we ARE compattible ;-)) > > > well - adding useful functionality seems like a pretty good reason - > especially when the Ant behaviour is only there because they lack an > expression system. Is that indeed the reason ? > > >AND break backward compatibility for NAnt > >users. > > > > > > > Sure - of course breaking compatibility is a bad thing generally - > however in this case I think there are probably more users who are > frustrated/confused by the current behaviour than are > actively relying > on it. I could be wrong though - I'd love to get peoples > opinions on this. Yeah, me too. I have no problem with this change, if our user base (and not just one or two persons) agrees its for the best, and if the Ant developers only implemented it like this because they do not have an expression system. > > >If we keep the current behaviour (which I'd prefer), then we > should at least > >document it better, t make it more clear/obvious to users. > > > sure but documenting should be secondary to having it do the > right thing. But we should at least make sure the new behavior is clearly documented, and announced as a (major) breaking change (if we decide to change this behavior). Gert ------------------------------------------------------- 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
