#546 Call Target and cascade=false prevents target re-execution

0.85
closed-fixed
Tasks (408)
7
2007-03-11
2006-04-21
No

When I set the cascade flag to flase on the call task,
the called target it self is not re-executed.

<project default="build">
<target name="init" />
<target name="compile" depends="init" />
<target name="build">
<call target="compile" cascade="false" />
<call target="compile" cascade="false" />
</target>
</project>

Expected behavior:
build:
init:
compile:
compile:

Actual behavior:
build:
init:
compile:

I'm using the nightly from 2006-03-08
I believe it's a problem in Project.cs
public void Execute(string targetName, bool
forceDependencies)
lines 884 and 885
if (forceDependencies || !currentTarget.Executed) {
currentTarget.Execute();
}
currentTarget will eventually end up being the called
target, and its execution state is checked just like if
its another of the depended targets.

Discussion

  • Gert Driesen

    Gert Driesen - 2006-05-01
    • status: open --> closed
     
  • Gert Driesen

    Gert Driesen - 2006-05-01
    • assigned_to: nobody --> drieseng
    • status: closed --> closed-invalid
     
  • Gert Driesen

    Gert Driesen - 2006-05-01

    Logged In: YES
    user_id=707851

    This is actually by design. The <call> task will not re-
    execute a target unless "cascade" is set to "true".

     
  • Michael@rubicon

    Michael@rubicon - 2006-05-01

    Logged In: YES
    user_id=1505249

    Thanks for clarifying. May I recommend updating the
    call-task's xml-comment, because it explicitly states otherwise.

     
  • Gary Feldman

    Gary Feldman - 2006-05-01

    Logged In: YES
    user_id=847172

    The internal documentation in CallTask.cs looks correct to
    me, which is not to say it couldn't be made clearer.
    Exactly which sentence or sentences are you interpreting as
    saying the opposite?

     
  • Michael@rubicon

    Michael@rubicon - 2006-05-01

    Logged In: YES
    user_id=1505249

    --- From the remarks section ---
    When the CallTask is used to execute a target, both that
    target and all its dependent targets will be re-executed. To
    avoid dependent targets from being executed more than once,
    two options are available: ... Set the CascadeDependencies
    attribute to false.
    ---
    This remark never states that the actual called target will
    not be re-executed. Admittedly, it also doesn't say otherwise ;)

    More important, the example on compiling a debug and a
    release build shows that the called target should be
    re-executed:

    --- From the example in the xml comment ---
    /// <project default="build">
    /// <property name="debug" value="false" />
    /// <target name="init">
    /// <echo message="initializing" />
    /// </target>
    /// <target name="compile" depends="init">
    /// <echo message="compiling with debug = ${debug}" />
    /// </target>
    /// <target name="build">
    /// <property name="debug" value="false" />
    /// <call target="compile" />
    /// <property name="debug" value="true" />
    /// <call target="compile" />
    /// </target>
    /// </project>
    ...
    /// The CascadeDependenciesparameter of the CallTask
    /// defaults to true, causing the "init" target to be
    /// executed for both the "debug" and "release" build.
    ...
    /// build:
    /// init:
    /// [echo] initializing
    /// compile:
    /// [echo] compiling with debug = false
    /// init:
    /// [echo] initializing
    /// compile:
    /// [echo] compiling with debug = true
    /// BUILD SUCCEEDED
    ...
    /// If the "init" should only be executed once, set the
    /// CascadeDependencies attribute of the CallTask to false.
    ...
    /// build:
    /// init:
    /// [echo] initializing
    /// compile:
    /// [echo] compiling with debug = false
    /// compile:
    /// [echo] compiling with debug = true
    /// BUILD SUCCEEDED
    ---

    What I interpret into this piece of documentation:
    "Compile" is executed using the CallTask. And with cascade
    set to false, the example's output shows that "compile"
    should be re-executed, and only "init", on which "compile"
    depends on, would not be re-executed.

    But the actual code, and your explaination, indicate that
    compile shouldn't be re-executed either.

    So the second part of the example and the code contradict
    each other and should be brought back into sync.

     
  • Michael@rubicon

    Michael@rubicon - 2006-05-16
    • status: closed-invalid --> open
     
  • Michael@rubicon

    Michael@rubicon - 2006-05-16

    Logged In: YES
    user_id=1505249

    Reopened, since documentation and code still contradict each
    other, as shown in my last comment.

     
  • Gary Feldman

    Gary Feldman - 2006-05-16

    Logged In: YES
    user_id=847172

    Sorry for not responding to your clarification earlier, but
    yes, I now think you are correct.

    The <call> task has direct and indirect targets. The direct
    target is the one named in the target="target-name"
    attribute. The indirect targets are the dependencies of the
    direct target.

    The documentation says that the direct target will always be
    executed, but the indirect targets will only be executed if
    they haven't been executed before OR if cascade is true.
    However, the code treats the direct target the same as
    indirect targets, so it won't be executed if it has already
    executed, unless cascade is true. The example in the
    documentation serves as a good reproducer.

    I also agree with both the documentation and Mike's
    expectation, which is that the direct target should always
    be executed, which means I disagree with Gert's initial
    comment here.

    The fix, unfortunately, is non-trivial. The dependency
    logic is in Project.Execute, which is a public method that
    shouldn't be changed without ensuring that its clients won't
    break. My guess is that's ok, but it means reviewing all
    calls on it from both NAnt and NAntContrib code. There are
    other approaches, but this would produce the cleanest code.

    Since there's a documented workaround, fixing this can be
    postponed beyond 0.85.

     
  • Gary Feldman

    Gary Feldman - 2006-05-16
    • status: open --> open-postponed
     
  • Gary Feldman

    Gary Feldman - 2006-05-16
    • priority: 5 --> 7
     
  • Gert Driesen

    Gert Driesen - 2007-03-11
    • status: open-postponed --> closed-fixed
     
  • Gert Driesen

    Gert Driesen - 2007-03-11

    Logged In: YES
    user_id=707851
    Originator: NO

    This is now fixed in CVS.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks