Re: [cc65] Relative paths during compilation

Hi Uz,

>> Is this a bug, or feature (will be in future versions) that files
>> are included relative to the 'current directory', not to the
>> directory where the includer resides.

> Does anybody know how this is handled in other compilers? The standard doesn't
> say anything about directories, so it's depending on the implementation how
> the argument of #include is handled.

I'm pretty sure that it is VERY popular to interpret #include "" as
"search relative to the file containing this directive". At least all
compilers I use at work interpret it this way.

Two examples:

http://gcc.gnu.org/onlinedocs/cpp/Include-Syntax.html#Include-Syntax :
"This variant is used for header files of your own program. It
searches for a file named file first in the directory containing the
current file, then in the quote directories and then the same
directories used for <file>. You can prepend directories to the list
of quote directories with the -iquote option."

http://msdn.microsoft.com/en-us/library/36k2cdd4(v=VS.80).aspx :
"This form instructs the preprocessor to look for include files in the
same directory of the file that contains the #include statement, and
then in the directories of any files that include (#include) that
file. The preprocessor then searches along the path specified by the
/I compiler option, then along paths specified by the INCLUDE
environment variable."

> If I'm going to change the current behaviour, I can:
>
>  1. Remember the path of the current file and add it to the argument of
>     #include. This will get quite nasty because of the differences in path
>     separators, UNC paths in windows, and drives in DOS based operating
>     systems. I've managed to keep most of this stuff out of cc65, which is
>     one reason why the the tools are rather portable.

Does NOT feel good. Not even thinking about bringing back absolute
paths into the dependency files (which you just removed successfully).

>  2. Simply add the path of the current input file to the search list. This
>     would have the effect that following #include files would also be
>     searched using this path. I'm not quite sure about the consequences,
>     however. Currently, there is no definite order of search paths. It may
>     happen that a file is also found in some other search path. Anyway, this
>     seems to be the easier alternative. Or am I overlooking something?

If I can (only) choose between the current behaviour, 1.) and 2.) then
the choice is a no-brainer to me: 2.)

As one can see from the GCC and MSVC doc excerpts above things tend to
get a little fuzzy anyway if the first try ("relative to the file
containing the directive") fails.

And the workaround of adding -I <source directory> to the Makefile is
never better than 2.)

Regards,
Oliver
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.