Re: #import and PCH

[Geoff Keating <geoffk at geoffk dot org>]

> Date: Sat, 25 Jan 2003 23:24:13 +0000
> From: Neil Booth <neil@daikokuya.co.uk>

> Geoff Keating wrote:-
> 
> > Neil Booth <neil@daikokuya.co.uk> writes:
> > 
> > > 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.
> > > 
> > > It's not that bad.  Your patch adds a lot of code in comparison.
> > 
> > This isn't much code compared to what would be necessary to save and
> > restore the include file splay tree.
> 
> I think you need to elaborate quite a bit more.

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

> > > How about just removing #import?  What about #pragma once?
> > 
> > #pragma once is a problem for another day.
> 
> But it has problems that are identical to #import in every way.  At
> present, we have #include which works as well as we can make it.  Then
> we have #import and #pragma once, which behave identically brokenly.
> 
> I don't think making #import different yet again is progress.  I am
> convinced that two implementations of the same thing, namely multiple
> inclusion, in the code base is worse than the current situation.

I am open to proposals.  I will post a summary so far to
gcc@gcc.gnu.org to help the discussion.

> > > You don't need to use a real identifier.  You could prepend it with a
> > > space, or anything other than "#".
> > 
> > I thought of that, but was worried it might cause trouble with -dM.
> 
> But you labelled it built-in.  They're not dumped with -dM.

OK, I'll change that.

>  And you
> have introduced the #import <foo.h> and #import <./foo.h> inconsistency
> that you noted.  We don't have that at present.

It's not an inconsistency, it's just that the rules changed.

> > >  What if #import <a.h> is followed by #include <a.h> ?
> > 
> > This is an intentional change.
> 
> Silently?  With what justification?  I don't think this is progress.
> This looks like documenting around a broken implementation.

If you like I can make #include respect the guard macros as
well, but it seems like if we're changing the semantics of #import
anyway it would be better to drop that behaviour.

I'm not after progress, I just want to be back where we were before.

> I had hoped we could just scrap #import and #pragma once.  Nicola's
> message leaves me quite pessimistic - it seems that the stubborn
> insistance of some people in Apple, which to be honest I can quite
> understand, is impeding us doing the right thing in FSF GCC.  However,
> this problem is not one that will go away by ignoring it.
> 
> Clearly the best solution is that everyone agrees #import and #pragma
> once disappear.  But that doesn't look like it's going to happen when
> 90% of users view #import as working correctly.

Yes.  The resources that have been spent on this over time are
probably ten times or more what would have been needed to just get rid
of #import everywhere.

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