> The first approach that comes to my mind is to somehow have > the upper level NAnt file assemble the target list, and then > when all the targets have been addressed, it actually makes a > single call to the lower level NAnt file. > But I can't think of any way to do that within NAnt's current design.
After some thought, this seems to me to be the best way to do this (Read: This is the best way I could think of to do this) 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. Building up the target list is probably the biggest challenge, but that should be a tractable problem. > Another alternative is to partition the lower level NAnt file > so that there is one project wrapper file that includes the > body of the project from a separate (non-project) NAnt > include file. That way both the top level and lower level > files could include the same content, and then the top level > could be changed to invoke the appropriate targets directly > instead of through a subsidiary NAnt call, thus allowing NAnt > to remove redundant target executions. This is probably > easier to do right now. 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? Also, a note on this approach... I'm assuming you would use the call task to execute your worker targets. This actually 'resets' the dependencies on that target, so if you call the build target then call the test target, if the test target depends on the build target then the build target will still be executed twice. In this way, the nant target is currently superior in that you can specify multiple targets in one call to satisfy run-once dependencies. Perhaps it's worth adding a 'reevaluate-dependencies' (or similar) attribute to the call task which can be used to drive this behaviour... > I'm wondering whether anyone has any other ideas for > approaching this problem, short of redesigning our entire > build scheme. No other ideas, sorry... I have to say that it is issues like this that has greatly reduced my use of dependencies between potential top-level targets... That is, if I think it is possible that I might want to run the test suite without performing a build, then the test target shouldn't depend on the build target. Similarly, if the release target isn't dependent on the build target, then if the release fails because of a file lock (Say I've forgotten that I've got one of the release files open, so it can't be overwritten) I can just fix the lock issue (close the editor :-), then re-run just the release target. To satisfy dependencies, I'd include an 'all' target, which depends on each top-level target in turn. For other subsets of targets, I would either manually type them in each time, or create an umbrella target which does nothing but specify dependencies if used often enough. Works well for me, so far. -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 BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click _______________________________________________ Nant-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-users
