Re: [cc65] Relative paths during compilation

Hi!

On Sun, May 02, 2010 at 04:59:33PM +0200, silverdr@wfmh.org.pl wrote:
> 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")?

While thinking about your mail and Olivers, it seems to me that there is not
really a difference between both approaches.

The first approach takes the path from the current file, prepends it to the
new one and uses the result as the first try. The second approach adds the
path to the search list. Provided that it's the first entry, nothing else
happens than with the first approach: The directory is prepended to the path
name of the include file and if a file with this name exists, it is used.

So these two approaches are mostly identical, at least in their effects.

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

The complaint about the nastyness was actually a bit short sighted by me. If I
just concatenate the paths, and pass the result down to the operating system,
I won't have to care about the things mentioned above. I may end up with
something like

        s:..\../foo/bar.h

but it's up to the OS to make any sense out of that.

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

No, there are no target host specific defines. There are a few places where
measures are taken to cope with different compilers, but not with target
operating systems. But that doesn't mean that the sources will compile on
absolutely arbitrary systems. It is assumed that '/' or '\' is a path
separator, and it is assumed that the operating system is able to understand
'/' as a path separator. Or in other words, when checking for a path
separator, the software checks for '/' or '\', and it uses '/' when inserting
one. This works for all major operating systems(*) and even a few not-so-major
ones:-)

> If not at all then it would really be a pity to lose
> this "cleanness" but (without checking the sources) I somehow doubt it.

I think I mentioned more than one time that I don't like #ifdefs, so I've
tried hard to avoid them. Which - in case of a compiler or other command line
tools - is not too hard. So you must not doubt any longer, just believe it:-)

Regards


        Uz


(*) On unix based operating systems, one may actually create files with names
    that have a backslash in them. So one could construct cases where the
    algorithm doesn't work. But in reality the chance of encountering such a
    file name is almost zero.

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