precompiled headers

[Omer Shenker]

Hello,

I'm interested in getting automake to support GCC 3.4 precompiled 
headers. I've read what appears to be the only thread on this list that 
discusses them, and it seems that the idea fizzled out. (Please correct 
me if I am wrong.) I have thought about the issue, and though I am not 
very familiar with the automake internals yet, I am willing to try 
coding it myself.

If you haven't yet, read the GCC manual's description of precompiled 
headers: <http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html>.


I would like to make several propositions regarding automake's support 
for precompiled headers:

A) It should be open to other compilers that support precompiled headers 
in slightly different ways, although support for GCC should obviously 
come first.

B) It should allow a project to declare that certain headers are 
precompiled without needing to know the implementation details (file 
extensions, locations, etc.).

C) It should work transparently on compilers without precompiled header 
support.

D) It should work within the existing dependency framework.


To that end I propose the following user interface:

1) The configure.{in,ac} should include the test AM_PRECOMPILED_HEADERS, 
which will probe for compiler support.

2) A Makefile.am should contain a PRECOMPILED_HEADERS variable listing 
header files that should be precompiled if possible. For example:
include_PRECOMPILED_HEADERS = all.h

3) On systems where precompiled header support is not detected, 
PRECOMPILED_HEADERS should work just like HEADERS.

4) The user then #includes all.h as usual in her source files, subject 
to the restrictions of GCC.

5) I'm pretty sure no one will consider a .gch file to be distributable 
or installable, because it's so fragile and flag-dependent. There's no 
reason to worry about supporting such things in the foreseeable future; 
they're like config.h.


I would also make these points about the implementation:

i) Because some users like to have read-only source trees and build 
elsewhere, the precompiled headers should be built in the build tree.

ii) This implies add an appropriate address@hidden@ _before_ the 
corresponding address@hidden@. (If it comes after, the non-precompiled header 
will be found first and the precompiled header will not be used.)

iii) Because precompiled headers are so fragile, we will often need to 
build multiple versions of them. Because of my lack of familiarity with 
automake internals, I'm not sure the best way to do this. Certainly it 
will involve the directory approach (e.g. mkdir all.h.gch). We will need 
one copy for each set of compiler flags that is used, and that includes 
the implicit -x for compiling C or C++ sources.

iv) Rules for building all the various versions of all.h.gch will need 
to include the explicit -x because otherwise the headers will never be 
compiled with __cplusplus defined. (Of course for C-only projects the 
C++ versions for all.h.gch will not be built, and likewise for C++-only 
code mutatis mutandis.)

v) The files that should depend on all.h.gch/* are the headers and 
source files that include all.h. Ideally GCC would output a dependency 
rule that foo.h (which includes all.h) depends on all.h and not 
all.h.gch. I will have to experiment to see if this is the case. If it 
is, we just need to output rules that make all.h.gch/* depend on all.h, 
and rules to build all.h.gch/*, and make will handle the rest. 
Unfortunately, this will probably lead to some unnecessary builds, for 
example if all.h includes bar.h only when in C++ mode, then a change to 
bar.h will cause the C versions of all.h.gch to be rebuilt, along with 
all the C source files...

vi) The .gch directories should be treated like .o files for the 
purposes of cleaning.


Thoughts? Again, I'm willing to put my time where my mouth is on this 
one, though without some help I doubt I'd do it the Right Way. :)

--
Omer Shenker