[C++-sig] gcc 3.4 pre-compiled header support?

[Jonathan Brandmeyer]

On Mon, 2004-01-12 at 13:14, Ralf W. Grosse-Kunstleve wrote:
> David and I put in some effort to ensure that the boost 1.31 release candidate
> works with gcc 3.4 from the most current gcc CVS. I am also interested in
> trying out the new pre-compiled header support but I have now clue where to
> start. Could someone please share her/his expertise?
> Thanks!
>         Ralf

Well, starting with the current documentation at
http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html#Precompiled%20Headers
and some experimenting, this is what I've found.

I don't know anything about an -fprecompiled-headers option that Mr.
Douglas mentioned, but what I've been experimenting with is using
explicitly generated PCH files.  Basically, you compile a header file
with exactly the same options that you would use to compile a source
file, except that the output is the full name of the original file with
.gch appended to it.  Files ending in .h and .hh are automatically
recognized as a header file to be precompiled, however .hpp files are
not.  To work around this and other issues I've ran into, I made a dummy
file boost_python.h that #includes <boost/python.hpp> and does nothing
else.  Then I precompiled that file and used the -include option to
force it into the compile of every .cpp file in Boost.Python.

Compiling libboost_python.so takes about 2 min on my system without PCH
enabled, and with PCH enabled it gets done in 44 seconds.  For my own
project, the times were 6:56 without and 4 min with PCH support.

But, there are several issues: 

Symbols in anonymous namespaces are colliding, resulting in linker
errors.  So, I haven't successfully linked libboost_python.so or my own
project module with PCH enabled.

If the header file that was precompiled is explicitly #included more
than once from the source file being compiled, either directly from that
.c/.cpp source file or indirectly via other header files, than for every
inclusion other than the first, an error is produced regarding a bad
file descriptor.  For a practical example, say you have two header files
that #include "config.h" for the project, and that you choose to make
config.h your PCH (since you can have only one).  Now, if a source file
includes both of those header files, than for the second inclusion of
config.h, you will get the error.  This does not extend to any of the
header files that config.h would include.  If config.h included <vector>
for example, and another source file included <vector> as well as
config.h than no error is generated.


The .h.gch file must be in the same directory as the header file
actually being included.  To use the file anyway to build for multiple
targets, I created an (empty) dummy file of the same name in the build
directory.

I'll be submitting bugreports for these to GCC tomorrow afternoon.

BTW, compiling life_support.cpp with PCH enabled (but not with it
disabled) resulted in this error @ line 35: "none is not a member of
boost::python::objects::detail".  Explicitly calling
::boost::python::detail::none() fixed this error.


I hope this is a decent starting point for you.

-Jonathan