These kind of issues aren't all that uncommon in builds... how feasible is a meta-element <attribute> that can be nested under any element and decorates it with an attribute. If the <attribute> meta-element supported if/unless and lazy property evaluation, then it could be used to do the following:
<csc target="exe" output="...">
<attribute name="doc" value="${doc}" if="${property::exists('doc')}" />
...
</csc>
Disclaimer: concept blatantly stolen from xslt attribute element.
I haven't looked at NAnt's xml deserialisation code, so I don't know how feasible it is for one element to modify the contents of another element on deserialisation... which would be much preferable (IMHO) to having to explicitly code support for the attribute meta-element in all tasks that might use it.
Thoughts?
-T
On 4/21/05, Julien Sobrier <[EMAIL PROTECTED]> wrote:
Hello,
From the same source files, I need to create a couple of builds for
different frameworks, different debug values, ... and 1 with a doc.
So I define the main build:
<task name="build" ....></task>
Then, for each build I want to create, I set-up the properties and do a
<call> to "build":
<target name="debug"...>
<property name=".... />
<call name="build" />
</target>
This way works fine, except to generate the doc: I need to be able to
switch from
<csc target="exe" output="...">...</csc>
to
<csc target="exe" output="..." doc="...">...</csc>
I don't know how to do that inside "build"
Any idea?
Thank you
Julien
-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Nant-users mailing list
Nant-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-users
--
Troy
