Re: [cc65] Relative paths during compilation

From: <silverdr1wfmh.org.pl>
Date: 2010-05-02 16:59:33
On 2010-05-02, at 15:05, Ullrich von Bassewitz wrote:

> 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 didn't do any specific tests now but I recall naturally referring from one source file to a specific include by using the paths relative to the current source file. I. e. "my_header.h" refers to the same directory as the current source file. "../my_project_includes/my_include.h" to a file residing in a parallel directory, and so on. It has always been natural to me. That means that either I have been always lucky to use compilers that implement it that way or that this is actually quite common approach.

> 
> If I'm going to change the current behaviour, I can:
> 
>  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?

While you can of course put the current input file's path at the TOP of the search list, which would possibly make it work in most (all?) cases, it still leaves sort of "ambivalent feelings", doesn't it? And what about hierarchy traversing? I mean things like absolute paths or relative stepping out of the current dir ("../new_dir/new_header.h")?

>  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.

Maybe a stupid question but don't you have to process the different path styles in various places already? Don't you have any #ifdefs related to the target host platform? If not at all then it would really be a pity to lose this "cleanness" but (without checking the sources) I somehow doubt it. If OTOH you do this already in different places, then it might be a good candidate for some sort of encapsulation, which could keep it in one place and wouldn't change much when similar needs arise later on.

-- 
SD!

P. S. You made my day with the deps ;-) tnx once more.----------------------------------------------------------------------
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 16:59:40 2010

This archive was generated by hypermail 2.1.8 : 2010-05-02 16:59:42 CEST