FYI: The basedir attribute was removed from NAntTask before the 0.7.9.0
release. It was removed may 3rd.
I've actually started to make some changes locally that could help out
here. I'm toying with the idea of changing the way properties are
defined and used. Since we now have a Parent property on Element, it
would be possible to define properties relative to the Parent, without
needing to go directly to the Project. This gives us the ability to
scope properties.
Then we can do stuff like this.
<target name="foo">
<localproperties>
<!-- localproperties = special task that sets properties on parent
element, not target defined element -->
<!-- Properties only exist in foo target -->
<Property name="TargetOnly" value="foo"/>
</>
</>
In addition, if the NAntTask were derived from
TaskContainer/CompositeTask than we could embed the Property tasks
inside the nant tag. Then the Parent could set the properties on the new
project that NAntTask creates.
Here is the behavior I would expect for properties:
1.) Default = InheritAll (this is the way Ant does it, and I think
people expect to be able to use properties from the parent build file)
2.) -D: properties should be read-only and inherited. (It was specified
on the command line for a reason. If you don't want it read-only, do it
another way.)
3.) Any property specified in nant tag should override the current
value, unless it is read-only.
Now, there is another good point Mark brings up. We need to support
something like ant <available/>. Basically we need to be able to check
if a property exists. Then we can avoid problem b: below.
> -----Original Message-----
> From: [EMAIL PROTECTED]
[mailto:nant-developers-
> [EMAIL PROTECTED]] On Behalf Of Gerry Shaw
> Sent: Monday, June 24, 2002 10:35 PM
> To: [EMAIL PROTECTED]
> Subject: [nant-dev] FW: NAntTask Patch
>
> 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 :)
> > >
> >
> >
-------------------------------------------------------
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members!
JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
_______________________________________________
Nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
