[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

precompiled headers

From: Omer Shenker
Subject: precompiled headers
Date: Sun, 29 Feb 2004 17:02:40 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040115 MultiZilla/


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

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 should contain a PRECOMPILED_HEADERS variable listing header files that should be precompiled if possible. For example:

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]