I think you are on to something here. I only use NAnt right now to build release candidate code so don't have the need for multi configuration builds, but your idea is certainly good.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jaroslaw Kowalski Sent: Saturday, June 28, 2003 06:16 To: [EMAIL PROTECTED] Cc: NAnt Developers Subject: [Nant-users] LONG: New idea for handling build configurations Hi all! Recently Giuseppe has prepared a document that describes recommended build configurations. This document and c.a. 99.441% of all build files in the universe attempt to invent their own methods for setting up parameters like: debug, optimize, defines for master and child builds. THE PROBLEM: ============ Most of the time you see this: <property name="something.debug" value="..." /> <property name="something.optimize" value="..." /> and then <csc ... debug="${something.debug}" optimize="${something.optimize}"> </csc> and all <csc> tasks tend to use the same settings in the whole buildfile. I think that the following covers at least 80% of all cases: 1. Most of the build files are simple: they use a single setting for "debug", "optimize", "defines" in all their outputs. 2. Builds that have many subdirectories tend to pass their current settings to sub-builds (we have inheritance here). 3. Most of the time you want to have configurations like: "debug" and "release" configurations (perhaps something third, but nothing more). 4. Build files tend to produce their output to a single directory, because it's in accordance to .NET deployment model, so being able to specify a default target directory makes sense in general. 5. You need to write some boilerplate code even for the simplest tasks if you want any degree of flexibility THE SOLUTION - IDEA =================== My idea (not complete yet, but may serve as a base for some discussion) is to introduce a concept of configurations. The "configuration" would define and group the most commonly used settings (perhaps global properties) like: default value of "debug" parameter for all tasks default value of "optimize" parameter for all tasks default value of "defines" parameter for all tasks default value for output directory for all tasks (and perhaps even more reasonable defaults) You would invoke NAnt by specifying the build file and the configuration (both can have defaults specified in <project> tag. NAnt.exe -cfg:debug build would build target "build" with configuration "debug". It would be possible to build all configurations by something like NAnt.exe -cfg:all build The "configuration" definition would be provided by: NAnt: NAnt would provide reasonable defaults for flags like "debug", "optimize", "defines", and "output directory". They should be provided (perhaps in NAnt.exe.config) for "debug" and "release" configurations. command line: Users may want to override some particular setting on the command line nant.exe -D:default.csc.debug=false configuration file: (not well thought out, but I think it sould be possible so you don't need to specify long command lines) build file: Build file would contain a bunch of: <configuration name="debug"> <property name="default.jsc.debug" value="false" /> <property name="default.csc.debug" value="true" /> <property name="default.debug" value="true" /> <property name="default.csc.outdir" value="bin/debug" /> </configuration> <configuration name="release"> <property name="default.jsc.debug" value="false" /> <property name="default.csc.debug" value="true" /> <property name="default.debug" value="true" /> <property name="default.csc.outdir" value="bin/release" /> </configuration> As you can see I propose some form of default values inheritance. For example "csc" task whould look for the value for its "debug" parameter by looking at (in order): - the value specified in <csc> task - if it's not found, get it from "default.csc.debug" - if it's not specified, get the value from "default.debug" And all <csc> tasks would be reduced to: <csc target="winexe" output="test.exe"> <sources> </sources> </csc> instead of (ugly in my opinion): <csc target="winexe" output="${something.outdir}/test.exe" debug="${something.debug}" optimize="${something.optimize}" define="${something.define}"> <sources> </sources> ... </csc> The idea is to have ultra-clean, yet very flexible build files that would be very easy to create and maintain. I think it would be simple to implement it using current model of properties. What do you think? Jarek ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ Nant-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-users ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers