Re: #import and PCH

[Stan Shebs <shebs at apple dot com>]

Geoffrey Keating wrote:

> On Friday, January 24, 2003, at 01:53  PM, Stan Shebs wrote:
>
> > Geoffrey Keating wrote:
> >
> > > #import worked by setting a flag bit on cpplib's hash table.  This is
> > > somewhat annoying from a PCH perspective, and is kind of ugly too.
> > > This patch changes the behaviour so that #import uses macro
> > > definitions to track whether a header is included or not, and then
> > > PCH works with it automatically.
> > >
> > > Bootstrapped & tested on powerpc-darwin.
> > >
> > > I'll wait a bit before committing it so that people can comment.
> > Does this work right with symlinks?  #import depends on being able to
> > detect file identity (I know, bleah bad evil etc etc), so I should
> > think your guard macro needs to have an inode number or some such
> > embedded in it.
> >
> > Unfortunately this is not a hypothetical issue, a build of Mac OS X
> > will likely go down in flames if you get this wrong, since there
> > are cases of multiple #imports through different paths but all
> > symlinking to a single file.
> Yes, it now works by looking at the actual text of the #import.  So,
>
> #import "foo.h"
>
> is always "the same file", but not "the same" as
>
> #import "./foo.h"
Importing "foo.h" and "./foo.h" should only read in once, if "foo.h"
is found in the current directory.

> (for example).  If this won't work, we'll have to move to a 
> MD5-checksum solution, but this will impose a significant penalty on 
> #import users.
Yeah.  cpp-precomp records device numbers and inodes in its precomps,
and there were a couple rare crazy-making bugs where a filesystem
was unmounted and remounted during a make, and the device numbers
matched up to a different header file.  You're next door to the
largest mass of potential pitchfork-and-torch-wielders wrt #import,
so just be careful. :-)

Stan