Re: #import and PCH

[Geoff Keating <geoffk at geoffk dot org>]

> Date: Sun, 26 Jan 2003 00:11:24 +0000
> From: Neil Booth <neil@daikokuya.co.uk>

> Geoff Keating wrote:-
> 
> > OK.  I want to make #import work with PCH.  This means that something
> > is going to have to save a list of what files were #import-ed in the
> > PCH so that they don't get included again if a #import occurs after
> > the PCH file is restored.  There's already code to save macro
> > definitions in cpppch.c, but there's no code to save the splay tree
> > holding the 'cmacro' field.  What's more, you can't just save the
> > splay tree; it's keyed by absolute pathnames, which might not be valid
> > when the PCH is restored (say, if the source tree is copied to a
> > different machine).
> 
> I've not looked at your PCH implementation at all, so I'm ignorant,
> sorry.  But I assume that all is well with #include, otherwise things
> would be pretty bad.

PCH doesn't need to do anything special to support #include because
#include doesn't save any state.  For instance, PCH doesn't need to
worry about the macro-based #include optimisation, the file
will just get reread.

> #include works with a simple concept of an include guard; it doesn't
> need anything more fancy.  So what I don't understand is why #import
> can't fake such an include guard by preceding the simplified pathname
> by something, say '@', like I previously outlined.  This would mean
> GCC 3.3 semantics for GCC 3.4 PCH, and #pragma once and #import
> behave exactly as they previously have done.

I think my summary discussion covered why I don't want to do anything
that encodes pathnames in the PCH file.

> I can understand that you can do better for Apple GCC with specific
> assumptions about OS X,

No, I don't make any specific assumptions about the OS.

> but I don't understand how your patch is
> any better than what I have proposed from FSF GCC's point of view.

My patch is a clean design with separation between #import and the
path-searching machinery.  Your proposal isn't.  This is why I like my
patch.  However, I may end up doing something like your proposal
anyway, to avoid changing semantics.  I'm sure you will like it much
less than the original patch.

> I can only see degradation, and more special cases, to something
> that is already too specialized IMO.  GCC's preprocessor is the
> most complex and arcane w.r.t. includes, by a *long* way, that
> any other implementation I've seen.  I really don't want to make it
> any worse.

Right, that's why my original patch moved the handling of #import out
of the part that handled file searching.

-- 
- Geoffrey Keating <geoffk@geoffk.org>