On 4/21/05, Gary Feldman <[EMAIL PROTECTED]> wrote:
I think there is a way to do it, but it is a little more complicated than I like... Basically the NAnt.Core.Element class could be extended with late binding attributes, and an entry point defined to specify the time that these attributes should be evaluated. This should work for tasks and targets, because they can bind when Execute is called... not so sure about data types... or even if this should be applied to anything but tasks! Dynamic dependencies, anyone? Wouldn't work, would it? For that matter, some attributes should never be dynamic even on tasks, like if/unless. Maybe these properties could be declared static-binding?
Anyway, I might have a play with it over the next few weeks, and if I don't find any nasty side-effects with targets or other elements, then I'll submit it as a patch post-0.85.
PS- no offense, but some of the code to initialise the project and process the build file could use some refactoring :-)
I think most people use it, because it's currently the only way to do it :-)
It gets exponentially more annoying the larger the element needing repetition is, though. (IMHO) Allowing dynamic attributes seems like a much more scalable and maintainable solution for the build script author.
This looks like a good idea, but could be difficult to do generally
across all tasks.
I think there is a way to do it, but it is a little more complicated than I like... Basically the NAnt.Core.Element class could be extended with late binding attributes, and an entry point defined to specify the time that these attributes should be evaluated. This should work for tasks and targets, because they can bind when Execute is called... not so sure about data types... or even if this should be applied to anything but tasks! Dynamic dependencies, anyone? Wouldn't work, would it? For that matter, some attributes should never be dynamic even on tasks, like if/unless. Maybe these properties could be declared static-binding?
Anyway, I might have a play with it over the next few weeks, and if I don't find any nasty side-effects with targets or other elements, then I'll submit it as a patch post-0.85.
PS- no offense, but some of the code to initialise the project and process the build file could use some refactoring :-)
In the meantime, a simple approach that works today is to duplicate the
task invocation with if/unless attributes, and use a property to
indicate which to do:
In the setup targets:
<property name="generateDocs" value="true" /> <!-- or false -->
In the build targets:
<csc target="exe" output="..." doc="..." if="${generateDocs}" />
<csc target="exe" output="..." unless="${generateDocs}" />
It's annoyingly verbose, but I use this idiom frequently.
I think most people use it, because it's currently the only way to do it :-)
It gets exponentially more annoying the larger the element needing repetition is, though. (IMHO) Allowing dynamic attributes seems like a much more scalable and maintainable solution for the build script author.
--
Troy
