Re: precompiled header suggestion

[Tom Tromey]

> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:

adl> This sounds tricky.  Adding such a file as a dependency of each .o file
adl> means that _all_ of them will be updated whenever the .ghc changes.

Good point.  There are other possible approaches, though.

For instance, for a given program, we could generate:

am--program:  $(program_BUILT_SOURCES)
$(MAKE) program

... which is sort of like the BUILT_SOURCES implementation, but more
targeted.

That's sort of backward, since "make program" will no longer work as
expected.  But you get the idea...

I suppose this is sort of secondary, and the main thing is just to
have some automation for building the .gch file at all.

adl> Putting the .ghc in BUILT_SOURCES automatically will not work if
adl> the .ghc includes another BUILT_SOURCES indirectly (direct
adl> inclusion is ok because we can issue the dependency ourself).
adl> Maybe we can live with such a limitation?

Yeah, there could be some problems here.  But the user can always add
an explicit dependency (just adding the .h to the gch file's _SOURCES
would suffice).

adl> Also I presume some libraries will also want to install such
adl> files?  Can they be installed?  (Is this what install-pch is
adl> about in your libstdc++ quote?)  If so, such installation also
adl> needs to be conditional.

Honestly, I don't know too much about this.  I'd suggest we leave
open the possibility that they can be installed, though.

adl> Maybe it would be simpler to introduce a new primary

Yeah.  Another idea would be to recognize `*.gch' automatically in a
_SOURCES variable corresponding to a program or library.

Tom

Re: precompiled header suggestion

[Eric Siegerman]

On Fri, Oct 03, 2003 at 12:36:25AM +0200, Alexandre Duret-Lutz wrote:
>  Tom> There would also have to be a way to disable .gch support
>  Tom> for non-gcc compilers.
> 
> Also I presume some libraries will also want to install such
> files?  Can they be installed?  (Is this what install-pch is
> about in your libstdc++ quote?)  If so, such installation also
> needs to be conditional.

By "install such files", do you mean the .gch files?  IMO,
installing those anywhere (or otherwise exporting them from the
build tree where they were created) should be *strongly*
discouraged!  They seem to be pretty fragile, in that any change
to just about anything invalidates the .gch; and the GCC
documentation admits that the compiler can't check for all such
cases (though they do appear to come admirably close).

Thus, it seems to me that the .gch should remain as local, and as
easily blown away and rebuilt, as possible -- and stashing the
thing in /usr/local/include violates both of those!

A .gch adds no value; it's purely an optimization.  Nothing wrong
with that, of course -- as long as it doesn't cause breakage.
But the cost of bad compiles if GCC doesn't notice that it should
ignore a bogus .gch, is likely to be a lot higher than the cost
of rebuilding the .gch somewhat more frequently than the
theoretical minimum.  And since GCC can't guarantee to avoid such
bum compiles, the build system should do what it can to help
avoid them.

The situation seems very similar to that of Autoconf's
config.cache.  Those files used to be kept between runs by
default, but it was decided that doing so causes too many
problems, so now the default is to throw them away; the user must
ask for the less-safe behaviour.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|  |  /
When I came back around from the dark side, there in front of me would
be the landing area where the crew was, and the Earth, all in the view
of my window. I couldn't help but think that there in front of me was
all of humanity, except me.
- Michael Collins, Apollo 11 Command Module Pilot

Re: precompiled header suggestion

[Alexandre Duret-Lutz]

>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:

[...]

 Tom> Automake could usefully automate this.  First, when building the .gch
 Tom> file we could do automatic dependency tracking (the process of
 Tom> building this file should support the normal -M flags).

Great.

 Tom> Also, if a .gch file is listed in _SOURCES, it would be cool to build
 Tom> this file before trying to build any of the objects associated with
 Tom> the _SOURCES variable.  (This could be generalized to all .h files,
 Tom> perhaps, to let us reduce the scope of BUILT_SOURCES.)  This could be
 Tom> implemented by adding a new dependency for each .o file.

This sounds tricky.  Adding such a file as a dependency of each .o file
means that _all_ of them will be updated whenever the .ghc changes.
Sounds like a loss.

Putting the .ghc in BUILT_SOURCES automatically will not work if
the .ghc includes another BUILT_SOURCES indirectly (direct
inclusion is ok because we can issue the dependency ourself).
Maybe we can live with such a limitation?

 Tom> There would also have to be a way to disable .gch support
 Tom> for non-gcc compilers.

Also I presume some libraries will also want to install such
files?  Can they be installed?  (Is this what install-pch is
about in your libstdc++ quote?)  If so, such installation also
needs to be conditional.

[...]

 Tom> We could probably already get most of this by abusing _PROGRAMS.
 Tom> That's ugly though.

Ouch. handle_programs does a great deal of work on _SOURCES
variables: looking for languages, rewriting sources into
objects, etc.  It also supports things like _LDADD etc.  All
these seem useless for compiled headers.

Maybe it would be simpler to introduce a new primary (I failed
to find a cunning name).  Obviously we need to support
sub-variables such as _SOURCES or _CPPFLAGS just like _PROGRAMS
does, but the logic would be much simpler than in _PROGRAMS
because there is no need to explore these variables.  (At least
I think there is no need, is this true?)
-- 
Alexandre Duret-Lutz

Re: precompiled header suggestion

[Tom Tromey]

> "Rob" == Robert Collins <[EMAIL PROTECTED]> writes:

>> Recently gcc added precompiled header support.  This is mostly useful
>> for C++, but C might benefit in some cases too.

Rob> Are you planning on doing this, or just sketching the design and hoping
Rob> for volunteer contributions?

I'm hoping someone else will do it :-)


Rob> What might be a useful starting point is some manual test cases or
Rob> sample rules, to aim for.

No problem.  libstdc++ is already using it.  I've appended some
snippets from their Makefile.am.

We could probably already get most of this by abusing _PROGRAMS.
That's ugly though.

I've also appended the section of the gcc manual explaining
precompiled headers.

Tom


pch_input = ${host_builddir}/stdc++.h
pch_output_builddir = ${host_builddir}/stdc++.h.gch
pch_source = ${glibcxx_srcdir}/include/stdc++.h
PCHFLAGS=-Winvalid-pch -Wno-deprecated -x c++-header $(CXXFLAGS)
if GLIBCXX_BUILD_PCH
pch_build = ${pch_input}
pch_install = install-pch
else
pch_build =
pch_install =
endif

# Build a precompiled C++ include, stdc++.h.gch.
${pch_input}: ${allstamped} ${host_builddir}/c++config.h ${pch_source}
touch ${pch_input}; \
if [ ! -d "${pch_output_builddir}" ]; then \
  mkdir -p ${pch_output_builddir}; \
fi; \
$(CXX) $(PCHFLAGS) $(AM_CPPFLAGS) ${pch_source} -O0 -g -o 
${pch_output_builddir}/O0g; \
$(CXX) $(PCHFLAGS) $(AM_CPPFLAGS) ${pch_source} -O2 -g -o 
${pch_output_builddir}/O2g;



@node Precompiled Headers
@section Using Precompiled Headers
@cindex precompiled headers
@cindex speed of compilation

Often large projects have many header files that are included in every
source file.  The time the compiler takes to process these header files
over and over again can account for nearly all of the time required to
build the project.  To make builds faster, GCC allows users to
`precompile' a header file; then, if builds can use the precompiled
header file they will be much faster.

To create a precompiled header file, simply compile it as you would any
other file, if necessary using the @option{-x} option to make the driver
treat it as a C or C++ header file.  You will probably want to use a
tool like @command{make} to keep the precompiled header up-to-date when
the headers it contains change.

A precompiled header file will be searched for when @code{#include} is
seen in the compilation.  As it searches for the included file
(@pxref{Search Path,,Search Path,cpp.info,The C Preprocessor}) the
compiler looks for a precompiled header in each directory just before it
looks for the include file in that directory.  The name searched for is
the name specified in the @code{#include} with @samp{.gch} appended.  If
the precompiled header file can't be used, it is ignored.

For instance, if you have @code{#include "all.h"}, and you have
@file{all.h.gch} in the same directory as @file{all.h}, then the
precompiled header file will be used if possible, and the original
header will be used otherwise.

Alternatively, you might decide to put the precompiled header file in a
directory and use @option{-I} to ensure that directory is searched
before (or instead of) the directory containing the original header.
Then, if you want to check that the precompiled header file is always
used, you can put a file of the same name as the original header in this
directory containing an @code{#error} command.

This also works with @option{-include}.  So yet another way to use
precompiled headers, good for projects not designed with precompiled
header files in mind, is to simply take most of the header files used by
a project, include them from another header file, precompile that header
file, and @option{-include} the precompiled header.  If the header files
have guards against multiple inclusion, they will be skipped because
they've already been included (in the precompiled header).

If you need to precompile the same header file for different
languages, targets, or compiler options, you can instead make a
@emph{directory} named like @file{all.h.gch}, and put each precompiled
header in the directory.  (It doesn't matter what you call the files
in the directory, every precompiled header in the directory will be
considered.)  The first precompiled header encountered in the
directory that is valid for this compilation will be used; they're
searched in no particular order.

There are many other possibilities, limited only by your imagination,
good sense, and the constraints of your build system.

A precompiled header file can be used only when these conditions apply:

@itemize
@item
Only one precompiled header can be used in a particular compilation.
@item
A precompiled header can't be used once the first C token is seen.  You
can have preprocessor directives before a precompiled header; you can
even include a precompiled header from inside another header, so long as
there are no C tokens before the @code{#include}.
@item
The precompiled header file must be produced for t

Re: precompiled header suggestion

[Robert Collins]

On Wed, 2003-10-01 at 04:30, Tom Tromey wrote:
> Recently gcc added precompiled header support.  This is mostly useful
> for C++, but C might benefit in some cases too.

Waay cool.

Are you planning on doing this, or just sketching the design and hoping
for volunteer contributions?

What might be a useful starting point is some manual test cases or
sample rules, to aim for.

Rob

-- 
GPG key available at: .

precompiled header suggestion

[Tom Tromey]

Recently gcc added precompiled header support.  This is mostly useful
for C++, but C might benefit in some cases too.

To use it, you make a special `.gch' file by compiling a bunch of .h
files.  Then you tell gcc to use it when compiling.

Automake could usefully automate this.  First, when building the .gch
file we could do automatic dependency tracking (the process of
building this file should support the normal -M flags).

Also, if a .gch file is listed in _SOURCES, it would be cool to build
this file before trying to build any of the objects associated with
the _SOURCES variable.  (This could be generalized to all .h files,
perhaps, to let us reduce the scope of BUILT_SOURCES.)  This could be
implemented by adding a new dependency for each .o file.

There would also have to be a way to disable .gch support for non-gcc
compilers.

Tom