Re: cpplib

Re: cpplib

[Rayson Ho]

It would help if you can define what you mean by "use"...

The IBM C++ compiler for PPC Linux links code it compiles against the
standard c++ runtime. So, if you are writing your own compiler, and
want to use the GNU C++ runtime, I think it's OK.

Rayson

> As I can use cpplib separately from gcc in own project?


__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

Re: cpplib

[Eric Christopher]

On Sat, 2003-12-06 at 14:00, Rayson Ho wrote:
> It would help if you can define what you mean by "use"...
> 
> The IBM C++ compiler for PPC Linux links code it compiles against the
> standard c++ runtime. So, if you are writing your own compiler, and
> want to use the GNU C++ runtime, I think it's OK.

cpplib is the preprocessor. libstdc++-v3 is the c++ standard library.

-eric

-- 
Eric Christopher <echristo@redhat.com>

cpplib

[Taras Brodovych]

How I can use cpplib separately?
Where I can get API for cpplib?

Re: cpplib

[Per Bothner]

Taras Brodovych wrote:

> As I can use cpplib separately from gcc in own project?

Yes - assuming of course that you don't violate the license.
Informally, any program that uses cpplib has to be GPL.

Note also that we make promises as to the stability of the cpplib API.
No compatibility is promised with future versions, even for "public"
functions.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

cpplib

[Taras Brodovych]

As I can use cpplib separately from gcc in own project?

Re: cpplib

[Zack Weinberg]

On Sat, 17 Apr 1999 03:09:14 GMT, Philipp Thomas wrote:
>Zack,
>as you're the one that has been hacking at cpplib, I thought you're the right
>one to ask (and I can't ask on the list as my relay is *still* ORBS blocked).
>
>Is cpplib ready for --enable-c-cpplib ? Seems not so, or are there other
>reasons why TARGET_SWITCHES are missing from --help ? 

No, cpplib is not anywhere near ready for --enable-c-cpplib.  You've
noticed one of the problems (lack of .i files in -save-temps).  Another
one is that .i files will be preprocessed again if you try to compile
them with an --enable-c-cpplib compiler.  There are definitely more bugs.

cpplib is almost ready to replace cccp (this is what you get with
--enable-cpplib) - just a matter of missing features now.  I'm aiming
for early in the 1.3 cycle.  If you want to help, I'd very much
appreciate it if you could test --enable-cpplib on a 64-bit machine
(Alpha, high end SGI, etc.)  We had some reports of failures on these,
and I can't debug it myself.

>And do you have a solution to get .i files when specifying -save-temps ? It's
>getting a nuisance to have to make a separate -E run to get the preprocessed
>files. I have looked into adding something myself but didn't quite find the
>point where one might be able to intercept.

The best fix here is probably to force use of the external
preprocessor when -save-temps is given.  You'd do that in the spec
strings in gcc.c and the various lang-specs.h files.  But first you'd
have to fix the bug where .i files get preprocessed again.

The idea I have to fix that bug is to implement a "stub" cpplib, which
uses the same cpp_reader data structure and interface, but all it does
is tokenize and interpret line markers.  This would be activated when
input is an .i file.  It's nontrivial but straightforward.

zw

Re: cpplib

[Zack Weinberg]

On Sat, 17 Apr 1999 03:09:14 GMT, Philipp Thomas wrote:
>Zack,
>as you're the one that has been hacking at cpplib, I thought you're the right
>one to ask (and I can't ask on the list as my relay is *still* ORBS blocked).
>
>Is cpplib ready for --enable-c-cpplib ? Seems not so, or are there other
>reasons why TARGET_SWITCHES are missing from --help ? 

No, cpplib is not anywhere near ready for --enable-c-cpplib.  You've
noticed one of the problems (lack of .i files in -save-temps).  Another
one is that .i files will be preprocessed again if you try to compile
them with an --enable-c-cpplib compiler.  There are definitely more bugs.

cpplib is almost ready to replace cccp (this is what you get with
--enable-cpplib) - just a matter of missing features now.  I'm aiming
for early in the 1.3 cycle.  If you want to help, I'd very much
appreciate it if you could test --enable-cpplib on a 64-bit machine
(Alpha, high end SGI, etc.)  We had some reports of failures on these,
and I can't debug it myself.

>And do you have a solution to get .i files when specifying -save-temps ? It's
>getting a nuisance to have to make a separate -E run to get the preprocessed
>files. I have looked into adding something myself but didn't quite find the
>point where one might be able to intercept.

The best fix here is probably to force use of the external
preprocessor when -save-temps is given.  You'd do that in the spec
strings in gcc.c and the various lang-specs.h files.  But first you'd
have to fix the bug where .i files get preprocessed again.

The idea I have to fix that bug is to implement a "stub" cpplib, which
uses the same cpp_reader data structure and interface, but all it does
is tokenize and interpret line markers.  This would be activated when
input is an .i file.  It's nontrivial but straightforward.

zw