-if i have a target with the depends attribute, the target(s) in the depends are executed only if they weren't executed previously.
-having the force attribute on the call task.
But i would agree in having the force attribute to true by default, as when I explicitly call a target i would expect it to alway be executed, but if i specify that a target depends on another target it's only to make sure that the specified target was executed.
Regards, Nick
----Original Message Follows----
From: "Gert Driesen" <[EMAIL PROTECTED]>
To: "Matthew Mastracci" <[EMAIL PROTECTED]>,"James C. Papp" <[EMAIL PROTECTED]>,"Nant-Developers (E-mail)" <[EMAIL PROTECTED]>
Subject: Re: [nant-dev] Re: Change to "call" task makes upgrade difficult
Date: Wed, 17 Mar 2004 08:18:30 +0100
Matthew, can you add this task to NAntContrib cvs ? Its in the NAnt patches tracker.
But I wonder if we should change it to use a collection of target elements, eg.
<depends>
<target name="..." if="${build.all}" />
<target name="..." />
<target name="..." />
</depends>That way you can also conditionally execute a certain target. (by the way: not sure I like the name of the task)
We could ofcouse always reinstate the force attribute of the <call> task, but in that case it should be true by default ...
Gert
----- Original Message ----- From: "Matthew Mastracci" <[EMAIL PROTECTED]> To: "James C. Papp" <[EMAIL PROTECTED]>; "Nant-Developers (E-mail)" <[EMAIL PROTECTED]> Sent: Wednesday, March 17, 2004 1:21 AM Subject: [nant-dev] Re: Change to "call" task makes upgrade difficult
> James C. Papp wrote:
>
> > This was also my rational of not just adding a flag to <call/>. The
<depends/>
> > task is just a dynamic form of the <target/> task's depends
attribute..., in
> > all other respect their ultimate functionality would be identical. The
> > <depends/> task was not meant to be used as a way to call targets, but
(more
> > accurately), to assert that a set of dependencies were meet or handled
(if
> > needed) before continuing. This is similar a little bit to .NET security
with
> > the way you can request certain privileges up front (as assembly
metadata), or
> > dynamically by asserting them within code.
>
> Heh... I just ran into the same problem you have. My workaround so far
> is to add the following attribute to all of my "execute-once" targets:
>
> unless="${target::has-executed(target::get-current-target())}"
>
> I would love to have the <depends/> task instead. :)
>
> Matt.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> nant-developers mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/nant-developers
>
>
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
_________________________________________________________________
MSN Messenger : discutez en direct avec vos amis ! http://messenger.fr.msn.ca/
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
