This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: #import future (summary and proposed solutions)
- From: kaih at khms dot westfalen dot de (Kai Henningsen)
- To: gcc at gcc dot gnu dot org
- Date: 27 Jan 2003 00:21:00 +0200
- Subject: Re: #import future (summary and proposed solutions)
- Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
- Organization: Organisation? Me?! Are you kidding?
- References: <4197B592-30C1-11D7-9E60-0050E4BAD278@apple.com>
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