This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: #import future (summary and proposed solutions)


geoffk@apple.com (Geoffrey Keating)  wrote on 25.01.03 in <4197B592-30C1-11D7-9E60-0050E4BAD278@apple.com>:

> These are the solutions that I've considered and not yet rejected.

[...]

11) Change #import as follows:

    Create a normalized version of the include file nams, such that every
    symlink therein is resolved, and that if a part of the name is on a
    case insensitive filesystem (I hope MacOS X has a way to find that
    out) it is replaced by a canonicalized (probably lowercased) version.
    (This should also be possible on other case-ignoring systems like
    Windows or DOS.)

    Then, define #import to use that normalized filename as file identity.

That would be more work than the current FSF identity relation, but  
(assuming it is even possible on MacOS X) not all that much more work: you  
need one OS-dependant "realpath" function (and various OSes already offer  
one); it would work reliably in the large majority of cases where it works  
in the current Apple version, and in all cases where it works in the  
current FSF version. And it would be completely predictable.

Wait, I hear you ask, what about copying source trees?

Put the same kind of marker in a PCH, but with the PCH filename; when you  
reread it and it doesn't match, reject the PCH with an "PCH file location  
moved, needs to be rebuilt" message. I don't think that's a major problem.  
It's not the only thing that's going to break, either, many source trees  
save some information about their position (that is, address some part of  
themselves with absolute paths). GCC has done that at least sometimes.

Drawbacks: it might not work in some exotic cases - perhaps the Windows  
version won't be able to work out that "Program Files" is the same  
directory as "PROGRA~1", or the Linux version might not be able to work  
out that the same partition is mounted in several different places - but  
then neither of these have reliable solutions today, and nobody can claim  
that using this kind of different paths to one file is sane. And anyway  
you can always just put the same file in two places and lose that way, ans  
the answer has always been "don't do that, then".

MfG Kai


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]