What do people think of this?  IMO the neseted properties for the nant
task seems to fall into line with the concept of Tomas's optionset idea.

-----Original Message-----
From: Mark Griffiths [mailto:[EMAIL PROTECTED]] 
Sent: Mon, June 24, 2002 2:32 AM
To: Gerry Shaw
Subject: RE: NAntTask Patch


I agree that basedir is not really required.  Once we realised that NAnt
figures out the basedir from the build file, we had no use for the
basedir attribute.

I still think that NAntTask would benefit from the nested property
elements. This feature makes 'parameterising' build files easier and
more explicit. In the absence of this patch we would have to rely on the
inheritall attribute like:

<property name="debug" value="false" />
<property name="evaluation" value="true" />
<nant buildfile="core/core.build" target="build" inheritall="true"/>
<!-- copy outputs to eval dir -->

<property name="evaluation" value="false" />
<nant buildfile="core/core.build" target="build" inheritall="true"/>
<!-- copy outputs to retail dir -->

Apart from being less explicit (IMO), there are two problems with this
approach:

a) If the evaluation property is specified on the command line, then the
two attempts to set the evaluation property will be ineffective.
(Admittedly an unlikely scenario).

b) More importantly, the child build file (core.build in this case) will
not be able to specify a value for 'evaluation', otherwise it will
override any value that has been inherited.  For core.build to be usable
in isolation of master.build, it will require property values to be
passed on the command line.

By using nested property elements, it not only becomes more explicit
what properties are being passed to the child build file, but the child
build file can also set default values for each property:

<nant buildfile="core/core.build" target="build" inheritall="false">
  <property name="evaluation" value="true" />
  <property name="debug" value="false" />
</nant>
<!-- copy outputs to eval dir -->
<nant buildfile="core/core.build" target="build" inheritall="false">
  <property name="evaluation" value="false" />
  <property name="debug" value="false" />
</nant>
<!-- copy outputs to retail dir -->

I am also starting to think that inheritall should be switched off by
default.  Allowing the child build to inherit every property feels a bit
too much like global variables to me.

I would be happy to write my thoughts up and try to convince the whole
NAnt developer community.  For your info I have included an updated
patch with the basedir attribute removed.

Please let me know what you think.

Thanks
Mark

> -----Original Message-----
> From: Gerry Shaw [mailto:[EMAIL PROTECTED]]
> Sent: 24 June 2002 01:18
> To: 'Mark Griffiths'
> Subject: RE: NAntTask Patch
>
>
> The plan is to abolish the basedir attribute and make it that the 
> basedir is implied by the directory where the build file is located. 
> The nant task would take into account if the specified build file was 
> in a different folder.
>
> This should make it far less complicated to figure out how to specify 
> include paths - just make them relative to the build file.
>
> With this in mind do you think we should apply this patch?
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]] On Behalf Of 
> > Mark Griffiths
> > Sent: Wed, June 19, 2002 9:30 AM
> > To: [EMAIL PROTECTED]
> > Subject: NAntTask Patch
> >
> >
> > Hi
> >
> > Attached is a patch for NAntTask that adds two new capabilities:
> >
> > a) NAntTask will now accept nested property elements that allow 
> > parameters to be passed to the subproject (the same as Ant).  The 
> > properties are added to the subproject as readonly properties.  This

> > allows the subproject to specify default values for each property, 
> > whilst allowing them to be overridden by a master build file or even

> > the command line -D: option.
> >
> > We found this facility useful for the following scenario. Our 
> > project has both evaluation and retail builds.  The only significant

> > difference between the two builds are the preprocessor definitions.

> > Cut down examples of these build files are:
> >
> > <!-- master.build -->
> > <project name="master">
> >   <property name="debug" value="false" />
> >   <nant buildfile="core/core.build" target="build"
inheritall="false">
> >     <property name="evaluation" value="true" />
> >     <property name="debug" value="${debug}" />
> >   </nant>
> >   <!-- copy outputs to eval dir -->
> >   <nant buildfile="core/core.build" target="build"
inheritall="false">
> >     <property name="evaluation" value="false" />
> >     <property name="debug" value="${debug}" />
> >   </nant>
> >   <!-- copy outputs to retail dir -->
> > </project>
> >
> > <!-- core.build -->
> > <project name="core">
> >   <property name="evaluation" value="false" />
> >   <property name="debug" value="false" />
> >   <!-- define preprocessor symbols -->
> >   <property name="define" value="DUMMY;" />
> >   <property name="define" value="DEBUG;TRACE;" if="${debug}" />
> >   <property name="define" value="${define}EVALUATION;" 
> > if="${evaluation}" />
> >   <!-- csc tasks etc -->
> >   <csc target="library" define="${define}" debug="${debug}" ...
> >     ...
> >   </csc>
> > </project>
> >
> > core.build defines defaults for evaluation and debug properties.  
> > This enables easy execution of core.build in isolation of 
> > master.build.
> >
> > b) The second capability is that NAntTask now accepts a basedir 
> > attribute that overrides any basedir derived from or specified in 
> > the subproject's build file.
> >
> > We initially added this feature because each of our build files 
> > specified basedir="." in the project element.  Then we discovered 
> > that, if the basedir attribute is not specified in the project 
> > element, NAnt will derive the base directory from the build file 
> > location.  Since discovering this behaviour, we have no use for the 
> > new NAntTask basedir attribute.
> >
> > If you feel that the NAntTask basedir attribute is not required, 
> > then feel free to either remove the appropriate code or let me know 
> > and I will send a fresh patch.
> >
> > Finally, if this patch is accepted I will be happy to update the 
> > documentation and unit tests for NAntTask.
> >
> > Mark
> >
> > BTW: NAnt Rocks :)
> >
>
>

Attachment: NAntTask.patch
Description: Binary data

Reply via email to