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. For example, you need to specify an object file before a library that resolves exports from this object file, otherwise you will get unresolved externals. Same for -u which forces an import on the command line: If you specify it after any libraries, it cannot be resolved. There are also the -( and -) switches that implement library groups - order is inherently important for these switches. So this seems to be more of a "it has always been this way, so I demand that it stays this way until time ends" type of things:-) Especially since with the new -o behaviour, you get a linker warning if something is about to be broken. > 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:-) Seriously: Please check if this change does really have an important impact. If so, and if it causes trouble for too much people, we can still think about ways to change it. Judging from my own experiences, the required changes are straightforward and manageable. I had to make changes to the library makefiles, because the rules for the drivers used the wrong order. The other rules were ok. Since these makefiles are more or less created as a copy of each other, doing it right one time will more or less guarantee that you won't have to care about it any longer. Regards Uz -- Ullrich von Bassewitz uz@musoftware.de ---------------------------------------------------------------------- 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 17:38:16 2010
This archive was generated by hypermail 2.1.8 : 2010-11-12 17:38:19 CET