From: groepaz (groepaz_at_gmx.net)
Date: 2001-12-10 19:57:26
Hello Ullrich, UvB> This is not correct. -I may be used for your own files and it may even be used UvB> within a project. In fact, cc65 itself uses -I to point to header files that UvB> are shared between the binary tools, it does *not* use relative paths. UvB> And, since directory handling is often non portable (there may be platforms UvB> with a different path separator, without a concept for a "subdirectory", or UvB> with a different notation for "parent directory") many guidelines for writing UvB> portable code say *not* to use a path in an include statement (the coding UvB> guidelines for the Mozilla project are an example). ok, for that reason, i could maybe understand (although practically a straight compile works fine for me for dos/win/linux/macos/amiga targets with liiiiiiiiiiiiiiiitle modification for each version - a handfull related functions for path-handling etc encapsulated in seperate files does the trick pretty well .... win/linux/macos should work without modification whatsoever) what do these guidelines say about how to name include files then? (it kinda makes having several files with the same name a lottery ..... hu which one will be included this time? ;=)) UvB> So I have to admit that I'm not really convinced. While it is possible to UvB> change the current behaviour, and it wouldn't be too much work, it UvB> * will increase code size and make the search routines more complex, yes surely will :O) just like shooting the lightbulb results in darkness ;D UvB> * will change the current behaviour and may break existing code, mmmh break existing code? how? wouldnt old code work just the same? (oh no, the "having several files with same name" problem hitting again right?) UvB> * may not meet other peoples expectations about the search algorithm. well i dont think so, really :=) most people probably wouldnt notice the difference anyway - except those who expect that kinda behaviour 'coz they knew it from the compiler they used before ;=) UvB> There are other details that will complicate the implementation: By using the UvB> path to an include file as the new search path for new include files, paths UvB> may "add up", getting longer and longer, eventually growing outside of some UvB> operating system limits (DOS for example has just about 60 characters for a UvB> path available). So special code would be required to cleanup path elements, UvB> and this code will require platform dependent knowledge - something I've UvB> managed to keep outside of the cc65 source until today. yes, surely, for a clean working implementation you need "expandpath" and "collapsepath" - which kinda need to be target-specific (well they'd have a handfull minor tweaks in #ifdef 's i'd say ;=)) UvB> For C compilers, the standard does not specify any search algorithm, it does UvB> not even talk about search paths or paths in include statements, and all this UvB> for a reason: It would be non portable to do so. yes maybe... but its still the way it is, all and every compiler i have tried (probably every "major" one there is plus tons of target-specific ones) behaves like this - except some really really old ones which do exactly behave like cc65 :o) -- Best regards, groepaz mailto:groepaz_at_gmx.net ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo_at_musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:44 CET