OK - I'm leaning toward your argument for items 1 and 2. I still think it complicates things - the semantics of the expression are more complicated than just "true" or "false" but it can make the build file shorter. essentially how C expression eval works ie null == false and not null == true if the argument isn't a boolean. I'm still a little concerned about having 2 methods of referencing properties - 1 where the property is just replaced with its value in place and another where its value looked up at evaluation time - kinda like having an identifier in c code used as both a macro and a variable.
I've just patched support for this into my local tree - its a simple enough change. I also think we can support the existing semantics as well. However I still don't think we should put the change into the upcoming release because:
1) I don't think its a showstopper - if it hasn't effected anyone in the last 8 months it can wait a little longer.
2) it changes the current behaviour and will break lots of current scripts and our current unit tests.
3) I think it needs more discussion
I'll put a patch up tomorrow and people can try it out.
I still don't agree with your 3rd point about not running dependent targets before evaluating.
I wasn't suggesting that they shouldn't be compared. I'm only saying that they don't have to be identical.Now I don't want to compare Ant and NAnt, but by choosing the name NAnt you're looking for it, no ? :-)
I agree that its shorter - intuitive is a trickier one. Although as I've said I think we can support both.Don't you agree that the Ant way of doing it is more intuitive and easier to maintain ? And the Ant version is shorter, and still offers more functionality (allows the user to input the build dir) ...
When it comes to significant behavioural changes to a product that is working well I would much rather hear a well thought out argument ( which you provided ) than "this is how it is in Ant".I hope you don't get all of this wrong, I really like NAnt ... And it has potential, but I don't understand why you choose not to follow in the footsteps of your big brother Ant ? Why not re-use the proven concepts of Ant ?
you've misread my reply. I did not say I didn't want to be compatible with Ant - I said "Full compatibility isn't necessarily a goal." - there is quite a difference.In the end, if you don't want to be compatible with Ant (and if you don't like the way Ant works), then why choose to name it NAnt ?
The two projects have been going there own ways for quite some time and have slightly different goals. From the website "NAnt is only compatible with Ant in spirit". As I said I have no problems looking at ideas from Ant I just
don't think we should view it as if it were a formal standard. I think Ant is great and its the reason I joined this project in the first place.
I'm not taking it negatively at all. Criticism welcome. I do however consider statements like "This is how Ant does it, and this is how it should be done !" slightly inflamatory, especially when not backed up by a reasonable argument.Please please please don't take this all negative, some criticism doesn't hurt, does it.
I reallly think you should update the docs to correct these
misunderstandings.
I totally agree.
>I would be glad to help you out on this, and other things much appreciated - patches alway welcome. Ian
----- Original Message ----- From: "Ian MacLean" <[EMAIL PROTECTED]>
To: "Gert Driesen" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Saturday, February 15, 2003 10:53 AM
Subject: Re: [nant-dev] serious BUGS in current CVS version !!
Gert,I've stumbled upon the following serious bugs in NAnt : when you want to execute a target (or task) only when a certain property has been set, you must use the unless attribute, like this : <target name="retrieve-NET-1.0-SdkRoot" unless="build.net10.sdkroot"> <readregistry property="build.net10.sdkroot" key="SOFTWARE\Microsoft\.NETFramework\sdkInstallRoot" hive="LocalMachine" failonerror="true" /> </target>in this case, the target should only be executed if the "build.net10.sdkroot" was not already set (using the commandline or anywhere else) or if it was set and its value couldn't be converted to a boolean true value. However, it seems as if there are actually three bugs in the way the if and unless attributes work in NAnt : 1. you can't directly specify a property name in the if and unless attribute, you must use ${ ...} when I specify the property name directy (without ${...}) I get the following error message : Cannot resolve to 'build.netcf10.sdkroot' to Boolean value.This seems reasonable to me. The ${} syntax is used to expand text in all attributes in the build file. It does no semantic checking at expansion time - it simply macro substitutes the actual property value. If the ${} syntax isn't used, how do you propose that we distinguish the property build.netcf10.sdkroot from the literal string "build.netcf10.sdkroot". The whole point of the ${} syntax is property expansion so I'm not sure why you'd expect to be able to reference properties without it.The documentation clearly states : if = the name of the property that must be set in order for this target to execute. unless = the name of the property that must not be set in order for this target to execute. this is different from the way Ant works, you should be able to specify a property name directly in the if and unless attribute (not using the ${....} syntax)2. when I specify the property name as ${propertyname}, I get the following error : Property 'project.config' has not been set!OK then I read this differently - maybe the documentation is incorrect here. This seems to me to be the difference between null/undefined and boolean false. It should probably read : if = an expression that must evaluate to true in order for this target to execute. you don't have to specify a property value at all. using unless="true" works just fine although its not very useful. Probably the reason for the mis-definition is that in NAnt, expressions can only be defined by properties using ${} or literal strings. so for example you can't say unless = "${foo} ==2", you can only do ${foo} or the literals "true" or "false". by this definition its working as it should. Referencing an undefined property gives the appropriate error. To get the desired behaviour the property should be defined and set to either true or false.The behaviour of the unless attribute should be : - check if the property exists - if it doesn't exist, exeute the target or taskI think the current behaviour is correct. In my opinion an undefined property shouldn't be treated the same as false.- if the property does exist, try to convert the value of the property to a boolean valueyep- if you can't convert it to a boolean value, consider the value to be "true" so don't execute the target or taskI disagree here. This check is valuable in catching property assignment errors - say if you intended to set a property to "true" but typed "tue" - in your scenario this would just cause the target to be skipped and the user would get no feedback that they had set the value incorrectly.- if you can convert the value to a boolean, execute the task or target when the value is FALSE, DON'T execute it when the value is TRUEI'm right with you here.I'm pretty sure this is how it should work, and I'm pretty sure that's how Ant works !Well I think thats open to discussion. I can't speak for how Ant works. There are a number of things we do differently to Ant. Full compatibility isn't necessarily a goal. If its the "right" thing to do - yes but not just because we want to do what Ant does.3. Apparently the if and unless attributes are evaluated before the dependent targets are executed, this is another major BUG. The dependent targets should be executed before the unless or if are evaluated. This is how Ant does it, and this is how it should be done !This one could be read either way. It seems to me that if you don't want a given target to build then you don't want its dependencies to build either - thats why you set the dependencies up that way in the first place - ie so that a target and its dependencies form an atomic unit of sorts. To turn off a whole chain of dependencies you would have to specify the 'unless' attribute for each target in the chain. Its certainly woth discussing but I wouldn't call it a showstopper.I think these are really show-stoppers, don't you agree ?I have to disagree. You've raised some valuable questions about how Nant executes targets and evaluates properties. However in my view the only real bug is lack of clarity in the documentation regarding the unless and if attributes. All these things have been that way since the if and unless attributes were introduced. I haven't had a problem with them being this way but maybe others have. Ian ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
