----- Original Message ----- From: "Ian MacLean" <[EMAIL PROTECTED]> To: "Gert Driesen" <[EMAIL PROTECTED]> Cc: "'Troy Laurin'" <[EMAIL PROTECTED]>; "'J. Christopher Six'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, December 03, 2004 9:58 AM Subject: Re: [Nant-users] Re: Segfault during compilation with mono on Linux
> Gert Driesen wrote: > > >>-----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" > > > > > > > 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. > >If your first use-case is that common, then how come it has taken several > >years for this to become an issue ? ;-) > > > > > > > fair point - I guess everyong has just worked around it up till now. 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). 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. > >>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 ? > > > > > > > Troy seemed to think so. Maybe Stefan is reading and can offer his > opinion. Personally I have no idea. I'll change the topic of this thread and "Cc" Stephane to get his attention ;-) > > >>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. > > > > > Excellent - we have reached agreement :) You didn't have doubts that we would, or did you ? ;-) > > >> 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). > > > > > totally - no argument there. Ok 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
