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