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