> Let me explain the problem in a bit more detail. > > [snip] > > So here's the question: Will the parent build invoke the > child once or twice?
Ahh, I see the problem. > 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. And waiting for "build success" to actually do anything just doesn't feel right, does it? > 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. Simpler for you :-) A function to list the current queue of targets to be run sounds like it has a pretty specific use... I'm really tempted to suggest that a design change is a more appropriate solution... > I had thought > that files invoked via <include> were not allowed to have > <project> elements, but in fact it's the other way around. Heh, fond (?!!) memories of trying to include shared behaviour in ant build files, but the only way to do this was using XML entities... Hooray for <include> :-) > >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. You're correct, I just don't know how to make the dependencies based on user-requested targets... unless the user is requesting targets exactly as they appear in the child build file, but then I don't see what the parent build file is doing... I'm obviously not looking at this the right way. > >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 All I can think of to suggest for the double invocation is to look at the design and see if it wouldn't be more appropriate to invert your build files. That is, rather than having your top-level build file having the common functionality and delegating to the specific project build file, use the project build file as your top-level build file which delegates to (or includes) the common build file for shared behaviour. It doesn't eliminate multiple nant invocations, but it might make them make more sense... And it might be worthwhile requesting project file caching, so repeat calls to the same build file don't have to reload/reparse the build file and so are much more performant. Probably worth adding an attribute to the nant task to force reload/reparse in this case, to support people who want to dynamically regenerate build files on-the-fly :-) I'm not sure if any of that helps, but I hope you get your build situation improved to your liking, -T Disclaimer Message: This message contains confidential information and is intended only for the individual(s) named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please immediately delete it and all copies of it from your system, destroy any hard copies of it, and notify the sender. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. To the maximum extent permitted by law, Immersive Technologies Pty. Ltd. does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. ------------------------------------------------------- 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
