Re: PATCH for a rather bad cpplib related bug

[Zack Weinberg <zack@rabi.columbia.edu>]

> > Yeah, I was wondering about that too.  Perhaps something like this would
> > be more appropriate?  (All the front ends that use cpplib call the reader
> > structure parse_in.)
>
> I  just  tried   a     similar  patch,   but    failed  in    the  ch/
> subdirectory. Since toplev.o is linked with  cc1chill but doesn't link
> with the various cpp*.o files, we just  end with an undefined external
> reference to "parse_in" :-(

Teach me to post patches without building the whole tree first...
Let's go with Dave's patch then.

> > I don't think this should be put into the release branch. 
> > --enable-c-cpplib isn't expected to work in 2.95 anyway.
>
> OK, I  always thought you  were trying  to push cpplib  and that  it's
> ready for prime time.  This  gives us some time  then to find a proper
> solution to deal with this mess.

There's a subtle difference between --enable-cpplib and --enable-c-cpplib. 
The former just uses the cpplib code to implement the external preprocessor. 
The latter links libcpp.a into several language front ends, so preprocessing
and parsing happen in the same task.

I push --enable-cpplib; it is almost ready for general use and I want wider
testing.  (There are some big hurdles to cover still, though.)
--enable-c-cpplib is not even remotely close to ready for prime time.

Neither of these options has any business holding up a release.

You might like to look at http://egcs.cygnus.com/proj-cpplib.html.  Any help
is appreciated (hint, hint...)

zw

p.s. I'm still not receiving mail you send me.