I certainly think this is a good way to go, but I don't fragment to quite the level you have here.
Basically, I have a file called generictasks.build which contains tasks such as compile, clean, assemblyinfo etc. Another file called properties.build contains property definitions that are global to the whole build process. This includes for example, archoive locations and the locations of build assemblies for referencing by other build files.
I then have an overall build script that controls the whole build process including dependencies, and then a build script for each individual assembly, which defines assembly specific properties and all the target definitions (these basically delegate to the targets in the generictasks file, but allow you the capabilirt to override the inplementation of a target for a specific assembly if necessary.
Doing stuff this way makes managing your builds a whole lot easier, especially when you want to change the way a compile if performed etc as it's only a change in one place rather that multiple build scripts.
HTH,
Bill
|
From "Michael Frederick" <[EMAIL PROTECTED]>@lists.sourceforge.net Sent by: [EMAIL PROTECTED] 19/07/2006 21:31 |
|
I'm working on converting some projects to using Nant for the build
infrastructure. It struck me that I should create a main structure and
then use <include>s to pull in the XML for each major step. This way I
could:
1) isolate the XML into discrete files.
2) re-use these files across products.
3) because of 1, I would have a much simpler main build file.
For example, if my build process was clean, get, compile, my main build
file would be:
<project name="main" default="go">
<target name="go" depends="clean,get,compile"/>
<include file="clean.build"/>
<include file="get.build"/>
<include file="compile.build"/>
</project>
With, for example, the file clean.build containing something like:
<project name="clean" default="go">
<target name="go" depends="clean"/>
<target name="clean">
<exec program="cmd" commandline="/c rmdir ${Clean.Root} /q /s"/>
</target>
</project>
But as I read and watch this list, I notice that it appears that few if
anyone is using this type of approach. What are the problems with the
approach? Why would you not use it? There are some issues,
-projecthelp doesn't expand the includes so you don't get a list of
targets contained in the included files.
But if I write the included files correctly, I can re-use them across
products. Any thoughts about using this type of structure?
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NAnt-users mailing list
NAnt-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-users
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
IMPORTANT
The information contained in this e-mail and any attachments is intended for the addressee only
and may contain legally privileged or confidential information. If you are not the intended
recipient you must not use, disclose, copy, distribute, alter, or take any action in reliance
on the information and Avon Insurance plc will not accept liability for any loss or damage howsoever
arising, directly or indirectly in reliance on it and gives no warranty or representation as to its
accuracy or reliability. If you are not the addressee, please notify us immediately on 01789 202121*
and delete the material from your computer and destroy any copies.
Avon Insurance plc reserves the right to monitor and record incoming and outgoing email messages for
the purposes of investigating or detecting unauthorised use of its system and ensuring its effective operation.
Avon Insurance plc will not accept liability for any loss or damage as a result of any virus being passed on.
Avon Insurance plc (No. 209606).
Registered in England. Registered Office: Arden Street, Stratford upon Avon, Warwickshire CV37 6WA.
Authorised and regulated by the Financial Services Authority.
A member of the NFU Mutual group of companies and the Association of British Insurers.
*For security and training purposes, telephone calls may be recorded and monitored.
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ NAnt-users mailing list NAnt-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-users
