From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2001-12-10 19:27:03
On Mon, Dec 10, 2001 at 04:54:02PM +0100, groepaz wrote:
> err... sorry, no :o) using -I is not a "clean" solution.... for once
> it would mean that each .inc file has to have a unique filename (which
> is not an option for me since i have "config.inc" etc in various
> directories) and nonetheless it makes it impossible to write code (and
> makefiles etc) that is totally independent of absolute local paths.
> from my understanding "-I" should be used to tell the assembler where
> to find "common" includes (such as common libraries of your "OS") but
> NOT where to find includefiles that are selfcontained within the code
> you are trying to compile.
This is not correct. -I may be used for your own files and it may even be used
within a project. In fact, cc65 itself uses -I to point to header files that
are shared between the binary tools, it does *not* use relative paths.
And, since directory handling is often non portable (there may be platforms
with a different path separator, without a concept for a "subdirectory", or
with a different notation for "parent directory") many guidelines for writing
portable code say *not* to use a path in an include statement (the coding
guidelines for the Mozilla project are an example).
So I have to admit that I'm not really convinced. While it is possible to
change the current behaviour, and it wouldn't be too much work, it
* will increase code size and make the search routines more complex,
* will change the current behaviour and may break existing code,
* may not meet other peoples expectations about the search algorithm.
There are other details that will complicate the implementation: By using the
path to an include file as the new search path for new include files, paths
may "add up", getting longer and longer, eventually growing outside of some
operating system limits (DOS for example has just about 60 characters for a
path available). So special code would be required to cleanup path elements,
and this code will require platform dependent knowledge - something I've
managed to keep outside of the cc65 source until today.
> whatever, all and all these problems can be easily solved by
> "searching relative to current file" aswell (right after searching
> pathes given by -I option at best) - and thats actually the kind of
> behaviour i'd expect from any decent compiler/assembler out there.
> (except borland turbo-c which suffers from the same problem hehehehe ;D)
For C compilers, the standard does not specify any search algorithm, it does
not even talk about search paths or paths in include statements, and all this
for a reason: It would be non portable to do so.
Regards
Uz
--
Ullrich von Bassewitz uz_at_musoftware.de
----------------------------------------------------------------------
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