On 2010-11-12, at 17:38, Ullrich von Bassewitz wrote: > On Fri, Nov 12, 2010 at 05:15:49PM +0100, silverdr@wfmh.org.pl wrote: >> While the whole idea sounds cool and promising, this above seems to >> me like a place to put a bit more effort to neutralise the side >> effects. I have to admit that I am allergic to forced order of >> options/parameters :-) > > Order has already been important before, so I cannot see why this is > a big > problem. Probably not THAT big of course :-) but as Oliver noted, it is quite common to a) experiment with various options before stoning things into script files b) defining output at the end So - not a very big problem, but a limitation that is not really "user- friendly" >> A quick question - wouldn't it be relatively easy to parse all the >> options before processing/executing them in a required order, >> regardless of how were they given on the command line? > > Doable: yes. Easy: no. It's a lot easier for me to require anybody > to change > their build scripts:-) I see ;-) If this is not easy to do (not sure how the parsing/ executing is done, but probably not with getopt-alike) then we shall have to live with that limitation. I thought the parsing could first build a kind of table and then execute the entries. This would remove all the order limitations, including the old ones for a noticeably more friendly command line tools that require less time to master. -- SD! ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Fri Nov 12 18:17:11 2010
This archive was generated by hypermail 2.1.8 : 2010-11-12 18:17:14 CET