----- Original Message -----
From: "Bonio Lopez" <[EMAIL PROTECTED]>
To: <nant-users@lists.sourceforge.net>
Sent: Tuesday, July 25, 2006 6:37 PM
Subject: [NAnt-users] Evaluation of if and unless
> Hi,
> 1.
> Following code returns a error:
> An empty string is not a valid value for attribute 'output' of <exec ...
> />.
> <property name="test.outputfile" value="" overwrite="false"/>
> <exec
> program="${expected.output}"
> commandline="${test.cmdline}"
> workingdir="${test.workingdir}"
> output="${test.outputfile}"
> unless ="${property::get-value('test.outputfile')==''}"/>
>
> The workaround would be
> <property name="test.outputfile" value="deadbeaf" overwrite="false"/>
> <exec
> program="${expected.output}"
> commandline="${test.cmdline}"
> workingdir="${test.workingdir}"
> output="${test.outputfile}"
> unless
> ="${property::get-value('test.outputfile')=='deadbeaf'}"/>
>
> Is it a supposed behavior and if yes, then what is the recommended
> approach
> to avoid the execution of test.outputfile="".
Currently we do not allow empty string values for System.IO.FileInfo backed
attributes.
This is indeed something we should look into changing (post-0.85), but I'm
not yet sure what's the best way of doing it.
Right now, setting the Required property on a TaskAttribute to true will
only result in a build failure if the given attribute does not exist on the
containing element of task. For string backed attributes, we added a
StringValidatorAttribute which features a AllowEmpty property that can be
used to specify whether a zero-length is allowed.
One option would be to change FileAttributeSetter (in Element.cs) to ignore
zero-length strings, and instruct task developers to apply a
StringValidatorAttribute (with AllowEmpty set to false) to properties that
are required to have a value; meaning the attribute should be specified on
the element/task in build files, and it should not have a zero-length value.
However, it might seem a bit awkward to apply StringValidatorAttributes to
FileInfo backed properties, no ?
Another solution for your problem would be to skip initializing
tasks/elements if the value of the "unless" attribute evaulates to true (or
the value of the "if" attribute evaluates to false), but we'll need to
discuss this further.
> 2.
> Sometimes I use targets to accomplish a repeating tasks. If I need to pass
> arguments to this target then I define a property. But may be there is a
> way
> to define target arguments?
> i.e.
> Now I do following:
> ...
> <property name="myarg1" value="1" />
> <property name="myarg2" value="2" />
> <call target="doSomething>
>
>
> < target name="doSomething">
> Work with myarg1 and myarg2
> </target>
>
>
> I would prefer something like:
>
> <call target="doSomething myarg1="1" myarg2="2">
>
>
> < target name="doSomething" arguments="myarg1,myarg2">
> Work with myarg1 and myarg2
> </target>
>
> Does it make sense? If not, how do you pass arguments to targets? Thru
> properties too?
Yes, and this is not something that is likely to be changed.
Gert
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NAnt-users mailing list
NAnt-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-users
