>From: "Troy Laurin" <[EMAIL PROTECTED]>
>Sent: Tuesday, July 27, 2004 9:49 PM
...
>What do you mean though, that you don't know how to do this with NAnt's
>current design? The 'target' attribute of the nant task allows
>specifying multiple space-separated targets, which will be called in
>order exactly if executing the child build file from the command line
>with those targets.
Let me explain the problem in a bit more detail.
Suppose both the parent and child build files have a "build" target and a
"test" target. And suppose that in the child build file, "test" depends on
"build". Hence, if you call the child file directly with either "build
test" or
"test" as the targets on the command line, it will only go through build
once
and test once.
Now suppose the parent file also has "build" and "test" targets. Since
users
often can't remember whether or not "test" depends upon "build", it's likely
(and for me almost a certainty) that the user will invoke the parent build
using "build" and "test" as targets.
So here's the question: Will the parent build invoke the child once or
twice?
If I invoke the parent with only "build", then it has to call the child with
a
target of "build." If I invoke it with "build test", then what I want is
for
it to not do the "build" invocation; it should only invoke the lower level
build file once. But in a straightforard build file design, the "build"
target
will have a <nant> task for the lower level file, as will the "test" target.
NAnt
will observe that the user specified both "build" and "test" on the
command line, and dutifully perform the "build" target, invoking the lower
level file once (and, as it turns out, unnecessarily), and then perform the
"test" target, invoking the lower level file a second time.
One way I envision working around this is to keep a property, call it
"lower-targets", and have the "build" target simply append the word
" build" to this property, and have the "test" target append the word "
test".
Then, after these targets have run, I want to invoke the lower level
build file, passing "${lower-targets" as the value of the "target="
attribute. But, other than onsuccess/onfailure, there's no way I can
see to tell NAnt to do this after both the build and test targets have
done their thing. Another, simpler alternative would be to add a
function that identifies all of the targets on the command line, or perhaps
just whether the current execution plan calls for invoking a particular
target.
That way, the "build" target in my example could interrogate that
information, to decide whether it needs to do the lower level call, or
allow a later target to do it.
>Just curious, why would you introduce an extra include file, and have
>both of your existing nant files include this? Would it not be
>sufficient for the top-level nant file to simply include the child
>(project?) nant file to implement this solution?
You're right, I misremembered the problem. I had thought that
files invoked via <include> were not allowed to have <project>
elements, but in fact it's the other way around.
>Also, a note on this approach... I'm assuming you would use the call
>task to execute your worker targets. This actually 'resets' the
No, with the <include> approach there's no need to use <call>. Just
make the targets in the top level file dependent upon the corresponding
targets in the lower level file.
>I have to say that it is issues like this that has greatly reduced my
>use of dependencies between potential top-level targets...
This is certainly the direction in which I am heading. And I agree, it
works well. It solves the repetition of the "build" target problem I
described above, but it doesn't solve the double invocation of the
<nant> task.
Gary
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Nant-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-users
