Here is a summary and a bit more of what I've been hearing so far.
There have been some great ideas.
We introduce the concept of "static" task properties. They can set in
the .build file but we also introduce two higher levels that can
initialize these properties as well.
For instance, the <csc> would have all it's current properties plus a
number of static properties like the location of the actual compiler.
This would allow us to move all the assumptions about the user's system
out of hard-coded strings and into the .config file.
The two additional levels of abstraction would be at the build file
level and at the machine level.
So now along with a ProjectName.build file you also have a
nant.core.config (in nant/bin) and optionally a ProjectName.build.config
(in the same location as ProjectName.build).
The values in the ProjectName.build.config override values in the
nant.core.config.
Here is an example of how it *might* be used. I'm not sure if its such
a good idea to allow the specific tasks be able to set their properties
but I can't think of a good reason why not.
Oh yeah, and don't feel bad to criticize this. *I* may not even like
this in a couple of days (nice philosophy Brad)
Example
-------
nant.core.config
<config>
<include file="rotor.config"/>
<task name="cl">
<property name="compiler" value="c:\VS.NET\bin\cl.exe"/>
</task>
</config>
rotor.config
<config>
<task name="csc">
<property name="compiler" value="c:\rotor\bin\csc.exe"/>
</task>
</config>
ProjectName.build.config
<!-- this project is built with mono but will still use
the VS.NET C++ compiler -->
<config>
<include file="mono.config"/> <!-- overrides the rotor config
properites -->
</config>
ProjectName.build
<project>
<target>
<csc>
<!-- this task uses the MS compiler -->
<property name="compiler" value="c:\VS.NET\bin\csc.exe"/>
...
_______________________________________________
Nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
