> > > What would be nice is a patch to exec's arg elements to delay
> > > expansion
> > > of properties in the same fashion as property's value
> attribute. It
> > > shouldn't be a difficult patch... if people are interested in this
> > > change, and I don't get indication that it's a bad idea,
> I'll have a
> > > look at it and submit a patch later today or tomorrow.
> >
> > That would be very nice. Thing is, would this just apply to <exec>,
> because I'm not sure if the same issue would appear in other
> tasks as well.
>
> Not sure its a good idea, it might just confuse users more ...
>
> Gert
My reason for this is that at least two people have been confused/bitten
by the current behaviour... with the current implementation, it seems
like you could specify optional arguments like:
<exec program="foo.exe">
<arg value="-q" />
<arg value="${foo.options}" if="${property::exists('foo.options')}" />
</exec>
That is, you can optionally specify -Dfoo.options=blah on the command
line to nant, which will be passed through to foo.exe during the build.
Unfortunately, the fact that the value attribute expands properties
eagerly means that it fails to be protected by the if statement. All I
intend for the patch to do is to delay property expansion until it is
determined that the argument value is actually required... if the patch
ends up changing the behaviour more than this, then I won't submit it,
because I messed up :-)
I'm not sure I explained that well... to sum up, I'm not sure why it
would confuse users at all, because it should appear to behave exactly
the same as it currently does, except it will no longer fail because of
missing properties if an arg's if/unless barrier condition means that
the arg is suppressed.
The only potential confusing issue is if the expression in the value
attribute has side-effects, such as:
<arg value="${path::get-temp-file-name()}" if="false" />
The temporary file will never be created, in the above.
-T
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the
> changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source
> Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Nant-users mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/nant-users
>
>
>
Disclaimer Message:
This message contains confidential information and is intended only for the
individual(s) named. If you are not the named addressee you should not disseminate,
distribute or copy this e-mail. Please immediately delete it and all copies of it from
your system, destroy any hard copies of it, and notify the sender. E-mail transmission
cannot be guaranteed to be secure or error-free as information could be intercepted,
corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. To the
maximum extent permitted by law, Immersive Technologies Pty. Ltd. does not accept
liability for any errors or omissions in the contents of this message which arise as a
result of e-mail transmission.
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Nant-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-users
