Re: [cc65] Relative paths during compilation

From: Ullrich von Bassewitz <uz1musoftware.de>
Date: 2010-05-02 15:05:04
Back to another topic:

On Thu, Jan 14, 2010 at 04:50:43PM +0100, Jakub wrote:
> 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. This behavior is for asm and C
> files (.incbin, #include).
> My project is getting bigger and I would like to split sources to
> different directories, but now I cannot do #include
> "..\upper_dir\otherfile.h", because it depends on the directory,
> where the compilation was started (by cl65).

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.

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.

  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?

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 Sun May 2 15:05:15 2010

This archive was generated by hypermail 2.1.8 : 2010-05-02 15:05:18 CEST