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-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers

Reply via email to