C Language, Precompiled header-files on Unix using Make ?

Precompiled header-files on Unix using Make ?

Author	Message
Lawrence Kir #1 / 4	Precompiled header-files on Unix using Make ? Quote: >Has anyone tried generating and using precompiled headers on the Unix >platform ? I'm not aware that too many Unix compilers have such a facility. Anyway this is a topic for comp.unix.programmer not comp.lang.c. Quote: >A little background on this. I've been using MS Visual C++ >at home recently that has this feature. Basically, the idea is that >since system library header-files rarely change it makes sense to >maintain a "compiled" version True. Quote: >(which I believe is a file generated by >running the headers through the preprocessor) which cuts down on the >compile time significantly. However this is far from true. assuming your compiler has in some sense a separate preprocessor (which is not required by the C language) all passing headers through it does is perform preprocessor directives and macro expansions on the contents of that particular header file. The macro definitions in particular are lost in the output of the preprocessor and therefore wouldn't be there to act on the user code. Also preprocessing doesn't deal with syntactic language constructs such as declarations and typedefs. True header compilation requires special support by the compiler to generate and read a "compiled" table of preprocessor macros and language declarations/definitions and any extras that the compiler supports, it is very different to simple preprocessed output. -- ----------------------------------------- -----------------------------------------
Fri, 06 Aug 1999 03:00:00 GMT

Kaz Kylhe #2 / 4	Precompiled header-files on Unix using Make ? Quote: >Has anyone tried generating and using precompiled headers on the Unix >platform ? >A little background on this. I've been using MS Visual C++ >at home recently that has this feature. Basically, the idea is that >since system library header-files rarely change it makes sense to >maintain a "compiled" version (which I believe is a file generated by >running the headers through the preprocessor) which cuts down on the >compile time significantly. I was thinking it would make our compiles >at work much faster if we maintained such "precompiled headers", more so > since many of the header-files are on NFS mounted directories. Also >all our programs use X and Motif libraries and their headers-files >are huge ! >The issues to be tackled are: >1) Maintaining a dependency of the "compiled header file" on the > various header-files it includes. >2) Making the use of precompiled-headers transparent to the code. In >other words, I should not have to modify #includes in existing source >code >Any tips or pointers will be appreciated. The C language does not specify the implementation of the pre-processing stage as a separate process, even though the standard is carefully contrived to allow the preprocessor to be implemented as a text filter. In the abstract definition of the C language, the output of the pre-processor consists of ``pre-processor tokens''. These could be implemented as a text stream that is subject to further lexical analysis, or they could be implemented as some sort of internal data type---e.g. lexemes carrying category information. The two ``issues'' you mention are the least of your worries in carrying out your plan: you have not thought this through carefully. Traditional UNIX-style C preprocessing (i.e. using a separate text translation phase the output of which is fed to the compiler proper) is done on an entire translation unit. You cannot perform it on portions of a translation unit (the included header files) individually and then use the results later. The main problem is that the pre-processor's symbol table does not appear in its output. Suppose you have the following header file: #define FOO_NUM 42 Question: what do you get when you run it through the text-substituting pre-processor? Answer: absolutely nothing. The pre-processor will parse the directive and remember the symbol FOO_NUM along with its list of replacement tokens. This information is held in volatile memory which is destroyed when the pre-processor reaches the end of the translation unit. To successfully ``pre compile'' header files, you will have to write a special preprocessor which can store not only the output, but also its symbol table, in some convenient format which can be summoned later. The TeX typesetting language has facilities for doing this sort of thing, with good reason: it depends heavily on the inclusion of macro files. There is no reason why a C implementation could not do the same thing, at least with the system supplied header files. Getting a pure text-filter preprocessor implementation to do it is another matter.
Fri, 06 Aug 1999 03:00:00 GMT

Kurt Watz #3 / 4	Precompiled header-files on Unix using Make ? Quote: >Has anyone tried generating and using precompiled headers on the Unix >platform ? >A little background on this. I've been using MS Visual C++ >at home recently that has this feature. Basically, the idea is that >since system library header-files rarely change it makes sense to >maintain a "compiled" version (which I believe is a file generated by >running the headers through the preprocessor) which cuts down on the >compile time significantly. I was thinking it would make our compiles >at work much faster if we maintained such "precompiled headers", more so > since many of the header-files are on NFS mounted directories. Also >all our programs use X and Motif libraries and their headers-files >are huge ! >The issues to be tackled are: >1) Maintaining a dependency of the "compiled header file" on the > various header-files it includes. >2) Making the use of precompiled-headers transparent to the code. In >other words, I should not have to modify #includes in existing source >code >Any tips or pointers will be appreciated. Preprocessing is a pretty straightforward process ;-), but parsing the resulting bundles of declarations is time-consuming. So without the help of your compiler, keeping "preprocessed" header files will not be very helpful. If your compiler supports dumping the results between parsing and code generation, and if it supports doing this on a per-header basis, you can use this feature. Keeping "preprocessed" versions of system headers, that depend on some header files and your makefile, because you would want to rebuild them if you change any defines that might affect them, like, e.g., POSIX_SOURCE, is simply not worth the effort, imho. Keeping _one_ "preprocessed" file that contains the bundeled, and, if you like, preprocessed contents of a _group_ of header files may be useful, because it may reduce file i/o during compilation. Note, however, that compiler implementors are free to simply punch the apropriate stuff into their current symbol table whenever they meet a line like "#include <stdio.h>" or something similar. As an aside: Does anyone know an implementation that does actually _use_ this liberty? Kurt Quote: >Thanks, >Rajeev Singh -- \| Kurt Watzka Phone : +49-89-2180-6254
Sat, 07 Aug 1999 03:00:00 GMT

James Youngm #4 / 4	Precompiled header-files on Unix using Make ? Quote: >Has anyone tried generating and using precompiled headers on the Unix >platform ? >A little background on this. I've been using MS Visual C++ >at home recently that has this feature. Basically, the idea is that >since system library header-files rarely change it makes sense to >maintain a "compiled" version (which I believe is a file generated by >running the headers through the preprocessor) which cuts down on the >compile time significantly. I was thinking it would make our compiles >at work much faster if we maintained such "precompiled headers", more so > since many of the header-files are on NFS mounted directories. Also >all our programs use X and Motif libraries and their headers-files >are huge ! GCC has an option that allows you to produce as output a "merged" header file that contains all the C text and all the #defines of its input, that you could use to produce a _single_ header file for all your source to include. Of course, you put a rule in the makefile for this so that it gets rebuilt when required. However, that requires GCC, and the details of it are buried in the info pages somewhere near the documentation for -MM and -dM. -- James Youngman VG Gas Analysis Systems The trouble with the rat-race Before sending advertising material, read is, even if you win, you're http://www.law.cornell.edu/uscode/47/227.html still a rat.
Sat, 07 Aug 1999 03:00:00 GMT

Page 1 of 1

[ 4 post ]