Gert Driesen wrote:
----- Original Message ----- From: "Gary Feldman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, September 13, 2004 5:53 PM Subject: Re: [Nant-users] Can't overwrite property when readonly not set
Although a <params> node with nested <param> element would definitely be more self-documenting, and would allow reporting (and verification) of the parameters that given build file accepts, I can see these issues / open topics :
- I think its obvious that we should enforce placement of this element at the top the build file. We currently have no mechanism for this, so we would have to code this as an exception to our normal initialization code. Not really a problem, but I thought I'd mention it anyway.
- We would have to make it a special case for our schema generation, if we want to enforce this element to be the first element under the <project> node.
I agree with both of these.
- The default value for such a param should not just be an attribute, but I think it would be best to allow a nested <default> node (or something) in which tasks/target can be executed to determine the default value.that seems a bit much. We don't have anything like that now for setting property values so why is it suddenly an imperative when it comes to params ?
- Do we only allow these explicitly defined parameters to be specified on the command line (and through the <nant> task) ? This would ofcourse break a lot of existing build files, unless we introduce sort of a schema version and only enforce it when the build file is at least schema version X.
Yes - I think so. That will clearly define available inputs to a build file. ALthough maybe inheriting properties via nant is a slightly different case.
I'm in two minds on this one. I notice that there is already a descrepency between the commandline and the nant task with regard to properties. When using <nant> inherited properties are passed thru 'as is' rather than readonly as are properties passed on the commandline. The <nant> task already has an OverrideProperties child element that would be replaced by a params element.
- Do we still allow property values to be inherited by nested build files (invoked using <nant>) ? It doesn't really make sense if you enforce explicit definition of params. Parameters that you want to pass to the nested build file should be explicitly defined, right ?
I see it the same way as fork works - ie the child process inherits specific environment from the parent instead of just the commandline args it would be if launched from the commandline.
I don't think I do disagree with most of them :) So it looks like this will involve significant and breaking changes. Sounds like a candidate for being done on a branch. That way if it turns out that its more trouble than its worth its not a big issue to undo.Don't hesitate to disagree with any of the above ;-)
Ian
--
Ian MacLean, Developer, ActiveState, a division of Sophos
http://www.ActiveState.com
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Nant-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-users
