I think that I like the idea of having configurable task properties be
normal properties as well. Combining this with Brad's aliases idea, we can
define aliases that look like normal tasks but are only missing lots of
attributes and/or child elements. As a really simple example:
<project>
<alias name="mycsc">
<csc debug="true" /> <!-- this would normally be invalid -->
</alias>
<target>
<mycsc>...</mycsc> <!-- this "inherits" the debug attribute from
above -->
</target>
</project>
Every occurrence of mycsc would be processed like a normal csc task. But
after checking to see if the mycsc task has an attribute (like debug in the
above example), it would check the alias if one wasn't found. This lets you
override attributes or elements that you set in an alias for each usage of
that alias.
For machine wide configuration, there could be a normal looking .build file
that just contains alias tasks in them to setup properties like compilerpath
on the csc task, for example. That machine wide config .build file would
just have all of its contents evaluated before every normal .build file
(like it was included).
This all sounds like more work to implement but more flexible, also. But
feel free to rip it apart. I might not even like it in a few hours.
Jason
----- Original Message -----
From: "Smith, Eric V." <[EMAIL PROTECTED]>
To: "NAnt Developers" <[EMAIL PROTECTED]>
Sent: Saturday, April 13, 2002 10:15 AM
Subject: RE: [nant-dev] RE: FileSet question
> I like the idea that the "static" properties are no different than any
> other properties. I was going to add the path name of cl.exe as a
> property to the cl task, but then thought better of it. With this
> scheme I just make everything a property that can be set in any of the
> config files.
>
> However, I don't see what the project.build.config file buys me, since
> it's in the same directory as the project.build file. What criteria
> would you use to put settings in one file versus the other? It seems
> tied strongly to the .build file, why not just put all of the settings
> in the .build file? In practice, I would probably have the machine
> config file and the project.build file. In my project.build file I may
> well include another .build file that has my usual settings, say
> "eric.config". This would set things like cl options, directories I
> often use, etc., and possibly some of the "static" properties, but none
> spring to mind just now. Maybe if I usually use one version of the
> compiler and for some set of projects I use a different version.
>
> I still think we need to have a command line option to specify a
> different nant.core.config file.
>
> And I might not like this either in a couple of days!
>
> Eric.
>
> > 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.
> >
> ...
> > 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)
>
> _______________________________________________
> Nant-developers mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/nant-developers
>
_______________________________________________
Nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
