GNU bug report logs - #8076
PCH support / howto

Previous Next

To reply to this bug, email your comments to 8076 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Olaf van der Spek <olafvdspek <at> gmail.com>
To: bug-automake <at> gnu.org
Subject: PCH support / howto
Date: Fri, 18 Feb 2011 13:58:25 +0100

Hi,

I just read http://sources.redhat.com/automake/automake.html#Examples
but didn't find anything on PCH.
Would it be possible to include a 'Hello World' style use of PCH?

-- 
Olaf

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Olaf van der Spek <olafvdspek <at> gmail.com>
To: bug-automake <at> gnu.org
Subject: Re: PCH support / howto
Date: Thu, 24 Feb 2011 12:53:19 +0100

On Fri, Feb 18, 2011 at 1:58 PM, Olaf van der Spek <olafvdspek <at> gmail.com> wrote:
> Hi,
>
> I just read http://sources.redhat.com/automake/automake.html#Examples
> but didn't find anything on PCH.
> Would it be possible to include a 'Hello World' style use of PCH?

Somebody?
-- 
Olaf

Message #13 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
To: Olaf van der Spek <olafvdspek <at> gmail.com>
Cc: bug-automake <at> gnu.org
Subject: Re: bug#8076: PCH support / howto
Date: Sun, 27 Feb 2011 13:08:53 +0100

severity 8076 wishlist
thanks

Hello Olaf,

* Olaf van der Spek wrote on Thu, Feb 24, 2011 at 12:53:19PM CET:
> > I just read http://sources.redhat.com/automake/automake.html#Examples
> > but didn't find anything on PCH.
> > Would it be possible to include a 'Hello World' style use of PCH?
> 
> Somebody?

Automake does not currently provide support for PCH out of the box.
Sorry.  There have been several discussions about this on the automake
lists.  Let me point to some informative posts:

http://thread.gmane.org/gmane.comp.sysutils.automake.general/5467/focus=5504
http://thread.gmane.org/gmane.comp.sysutils.automake.general/11619/focus=11628
http://thread.gmane.org/gmane.comp.sysutils.automake.general/3098/focus=3108
http://thread.gmane.org/gmane.comp.sysutils.automake.general/4099

I will probably not hack on this myself (both due to time constraints
and IMVHO limited portability/usefulness of PCH), but if somebody else
wants to pursue it, I'd help.  The above discussions can give some
insight into the issues around this.

Hope this helps.  If you have a good solution, even if it's just for
your project, feel free to post it here; we can link to it from the
FAQ or so, or even put it in the manual if it is sufficiently general.

Thanks,
Ralf

Message #16 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Olaf van der Spek <olafvdspek <at> gmail.com>
To: Olaf van der Spek <olafvdspek <at> gmail.com>, bug-automake <at> gnu.org
Cc: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
Subject: Re: bug#8076: PCH support / howto
Date: Sun, 27 Feb 2011 19:01:16 +0100

On Sun, Feb 27, 2011 at 1:08 PM, Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> wrote:
> I will probably not hack on this myself (both due to time constraints
> and IMVHO limited portability/usefulness of PCH), but if somebody else

PCH is IMO very valuable. GCC, ICC and MSVC support it, I'm not sure
about other compilers.
I've read your concerns, but I think they're not an issue.

> wants to pursue it, I'd help.  The above discussions can give some
> insight into the issues around this.
>
> Hope this helps.  If you have a good solution, even if it's just for
> your project, feel free to post it here; we can link to it from the
> FAQ or so, or even put it in the manual if it is sufficiently general.

It would be nice to add PCH support to the Hello World example. I
think this requires two steps:
1. Compile config.h into config.h.gch
2. Add config.h.gch as a dependency to all source files.

Could you (or someone else) help me with those? I've got no experience
with automake but I assume they're trivial for someone with
experience.

-- 
Olaf

Message #19 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Olaf van der Spek <olafvdspek <at> gmail.com>
To: Olaf van der Spek <olafvdspek <at> gmail.com>, bug-automake <at> gnu.org
Cc: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
Subject: Re: bug#8076: PCH support / howto
Date: Thu, 3 Mar 2011 16:41:15 +0100

On Sun, Feb 27, 2011 at 7:01 PM, Olaf van der Spek <olafvdspek <at> gmail.com> wrote:
> On Sun, Feb 27, 2011 at 1:08 PM, Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> wrote:
>> I will probably not hack on this myself (both due to time constraints
>> and IMVHO limited portability/usefulness of PCH), but if somebody else
>
> PCH is IMO very valuable. GCC, ICC and MSVC support it, I'm not sure
> about other compilers.
> I've read your concerns, but I think they're not an issue.
>
>> wants to pursue it, I'd help.  The above discussions can give some
>> insight into the issues around this.
>>
>> Hope this helps.  If you have a good solution, even if it's just for
>> your project, feel free to post it here; we can link to it from the
>> FAQ or so, or even put it in the manual if it is sufficiently general.
>
> It would be nice to add PCH support to the Hello World example. I
> think this requires two steps:
> 1. Compile config.h into config.h.gch
> 2. Add config.h.gch as a dependency to all source files.
>
> Could you (or someone else) help me with those? I've got no experience
> with automake but I assume they're trivial for someone with
> experience.

Somebody?

-- 
Olaf

Message #22 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Olaf van der Spek <olafvdspek <at> gmail.com>
To: bug-automake <at> gnu.org
Cc: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
Subject: Re: bug#8076: PCH support / howto
Date: Thu, 17 Mar 2011 12:05:31 +0100

On Thu, Mar 3, 2011 at 4:41 PM, Olaf van der Spek <olafvdspek <at> gmail.com> wrote:
> On Sun, Feb 27, 2011 at 7:01 PM, Olaf van der Spek <olafvdspek <at> gmail.com> wrote:
>> On Sun, Feb 27, 2011 at 1:08 PM, Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> wrote:
>>> I will probably not hack on this myself (both due to time constraints
>>> and IMVHO limited portability/usefulness of PCH), but if somebody else
>>
>> PCH is IMO very valuable. GCC, ICC and MSVC support it, I'm not sure
>> about other compilers.
>> I've read your concerns, but I think they're not an issue.
>>
>>> wants to pursue it, I'd help.  The above discussions can give some
>>> insight into the issues around this.
>>>
>>> Hope this helps.  If you have a good solution, even if it's just for
>>> your project, feel free to post it here; we can link to it from the
>>> FAQ or so, or even put it in the manual if it is sufficiently general.
>>
>> It would be nice to add PCH support to the Hello World example. I
>> think this requires two steps:
>> 1. Compile config.h into config.h.gch
>> 2. Add config.h.gch as a dependency to all source files.
>>
>> Could you (or someone else) help me with those? I've got no experience
>> with automake but I assume they're trivial for someone with
>> experience.
>
> Somebody?

Anybody? Please?


-- 
Olaf

Message #25 received at 8076 <at> debbugs.gnu.org (full text, mbox):

From: Olaf van der Spek <olafvdspek <at> gmail.com>
To: 8076 <at> debbugs.gnu.org
Subject: Re: bug#8076: PCH support / howto
Date: Fri, 1 Jul 2011 12:36:28 +0200

I think I found a way, at last:
BUILT_SOURCES = config.h.gch

config.h.gch: config.h
	${CXXCOMPILE} -o $@ $<


-- 
Olaf

Message #28 received at 8076 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Warren Young <warren <at> etr-usa.com>
Cc: 8076 <at> debbugs.gnu.org, Automake List <automake <at> gnu.org>
Subject: Re: PCH support
Date: Fri, 23 Dec 2011 22:10:32 +0100

On 12/23/2011 09:51 PM, Warren Young wrote:
> On 12/23/2011 9:46 AM, Stefano Lattarini wrote:
>>
>> I know basically nothing about PCH,
> 
> The only important thing to know is that it's a way to make the compiler dump
> its parse tree to disk during compilation so that it can simply reload that
> state from disk instead of rebuilding it from scratch for each module it builds.
> 
> You might think of PCH as a similar optimization to that of a bytecode compiler
> for a dynamic language: it doesn't get you native code, like you can get with a
> traditional static language, but you still get a speed benefit by avoiding
> reparsing.
> 
> PCH is most valuable with headers like STL which are commonly used across the
> program and are expensive to parse and reparse and re-reparse.
> 
>> and it seems to me that it is not
>> a feature many users would require or employ.
> 
> I think the idea is that if autoconf detects that PCH is available and
> automake generates the correct compiler commands to use it, it will be
> there "for free" to any user of the autotools.  Builds just get magically
> faster.
> 
> There's a monkey wrench, in that PCH doesn't work well if you don't 
> organize your header files to take advantage of it.  Say you have a
> program with 20 modules, and none of them have any commonality in their
> #include lines.  PCH might make such a build *slower*.  PCH gets its
> biggest benefit when you can make the includes as similar as possible
> across modules, at least up to a point.
> 
Thanks for the explanation.  With my present reply, I'm registering it in the
appropriate entry of the bug tracker, for future reference.

> Visual C++ avoids this trap by generating a header file for the project which
> you're supposed to #include in every module, and in which goes #includes for
> the most commonly used things.  (stdio.h, windows.h...) The project is
> configured to only generate PCH output for that one header, so there is none
> of the cache thrashing that happens in my 20-modules example.
> 
> I'm sure you care nothing for Visual C++,
>
Not personally, but the latest versions of automake are starting to provide
support to allow/facilitate compilation with MSVC on MSYS/MinGW (credit for
this mostly goes to Peter Rosin).  The NEWS entries from the latest 1.11.2
version of Automake contain:

  - The `compile' script now converts some options for MSVC for a better
    user experience.  Similarly, the new `ar-lib' script wraps Microsoft lib.

  - New macro AM_PROG_AR that looks for an archiver and wraps it in the new
    'ar-lib' auxiliary script if the selected archiver is Microsoft lib.

> but most of the people begging for PCH support are probably coming from
> this world.

> Bottom line, such a feature, if ever added, should probably be optional.
> 
Thanks for the tip.

Regards,
  Stefano

Message #31 received at 8076 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: 8076 <at> debbugs.gnu.org
Cc: Dave Hart <davehart <at> gmail.com>, Automake List <automake <at> gnu.org>,
	davehart_gmail_exchange_tee <at> davehart.net, Warren Young <warren <at> etr-usa.com>
Subject: Re: PCH support
Date: Fri, 23 Dec 2011 22:23:03 +0100

Hi Dave.

I'm quoting your mail and CC:ing <8076 <at> debbugs.gnu.org>, so that your reply
will be registered into the proper entry of the Automake bug tracker.

Anybody, please send further replies and follow-ups to that address if possible,
so that this discussion will be properly registered.

Thanks,
  Stefano

On 12/23/2011 10:11 PM, Dave Hart wrote:
> On Fri, Dec 23, 2011 at 20:51, Warren Young <warren <at> etr-usa.com> wrote:
>> The only important thing to know is that it's a way to make the compiler
>> dump its parse tree to disk during compilation so that it can simply reload
>> that state from disk instead of rebuilding it from scratch for each module
>> it builds.
>>
>> You might think of PCH as a similar optimization to that of a bytecode
>> compiler for a dynamic language: it doesn't get you native code, like you
>> can get with a traditional static language, but you still get a speed
>> benefit by avoiding reparsing.
>>
>> PCH is most valuable with headers like STL which are commonly used across
>> the program and are expensive to parse and reparse and re-reparse.
> 
> True, but most C/C++ #includes orders of magnitudes more lines than
> they contain themselves, so assuming the source code is rearranged to
> have a "precomp.h" containing the bulk of #includes, the compile will
> be notably faster.
> 
>> I think the idea is that if autoconf detects that PCH is available and
>> automake generates the correct compiler commands to use it, it will be there
>> "for free" to any user of the autotools.  Builds just get magically faster.
> 
> Given the source changes needed to leverage PCH, I suspect it'll take
> a bit of maintainer involvement to enable useful PCH support in each
> package.
> 
>> There's a monkey wrench, in that PCH doesn't work well if you don't organize
>> your header files to take advantage of it.  Say you have a program with 20
>> modules, and none of them have any commonality in their #include lines.  PCH
>> might make such a build *slower*.  PCH gets its biggest benefit when you can
>> make the includes as similar as possible across modules, at least up to a
>> point.
>>
>> Visual C++ avoids this trap by generating a header file for the project
>> which you're supposed to #include in every module, and in which goes
>> #includes for the most commonly used things.  (stdio.h, windows.h...) The
>> project is configured to only generate PCH output for that one header, so
>> there is none of the cache thrashing that happens in my 20-modules example.
>>
>> I'm sure you care nothing for Visual C++, but most of the people begging for
>> PCH support are probably coming from this world.
> 
> Another monkey wrench is gcc and Visual C++ have different models for
> how PCH is implemented.  Support in Automake would ideally target both
> by finding a compatible subset.  I'm sure there are existing
> open-source models that demonstrate how to use both gcc and VC
> precompiled headers.  As I recall, gcc support is a bit more generic
> but involves a separate PCH invocation to "compile" the headers, while
> VC++ requires precomp.h be the first item included in each
> participating file but doesn't require a separate compiler invocation
> -- the first one that can use the precomp.pch generates it.
> 
> The compile-time savings can be relatively huge.  Support in Automake
> would be lovely and I'd be happy to help test any patches.
> 
> Cheers,
> Dave Hart
> 

Message #34 received at 8076 <at> debbugs.gnu.org (full text, mbox):

From: Olaf van der Spek <ml <at> vdspek.org>
To: davehart_gmail_exchange_tee <at> davehart.net
Cc: Automake List <automake <at> gnu.org>, 8076 <at> debbugs.gnu.org,
	Warren Young <warren <at> etr-usa.com>
Subject: Re: PCH support
Date: Fri, 23 Dec 2011 22:58:56 +0100

On Fri, Dec 23, 2011 at 10:11 PM, Dave Hart <davehart <at> gmail.com> wrote:
> Another monkey wrench is gcc and Visual C++ have different models for
> how PCH is implemented.  Support in Automake would ideally target both

Have they? AFAIK they're equivalent.

> by finding a compatible subset.  I'm sure there are existing
> open-source models that demonstrate how to use both gcc and VC
> precompiled headers.  As I recall, gcc support is a bit more generic
> but involves a separate PCH invocation to "compile" the headers, while
> VC++ requires precomp.h be the first item included in each
> participating file but doesn't require a separate compiler invocation
> -- the first one that can use the precomp.pch generates it.

Both have a step to generate the PCH. VC builds stdafx.h via
stdafx.cpp, GCC builds a header file directly. Both basically require
the header to be the first include for PCH to be usable.

-- 
Olaf

Message #37 received at 8076 <at> debbugs.gnu.org (full text, mbox):

From: Olaf van der Spek <ml <at> vdspek.org>
To: Warren Young <warren <at> etr-usa.com>
Cc: 8076 <at> debbugs.gnu.org, Automake List <automake <at> gnu.org>
Subject: Re: PCH support
Date: Fri, 23 Dec 2011 23:06:03 +0100

On Fri, Dec 23, 2011 at 9:51 PM, Warren Young <warren <at> etr-usa.com> wrote:
> I think the idea is that if autoconf detects that PCH is available and
> automake generates the correct compiler commands to use it, it will be there
> "for free" to any user of the autotools.  Builds just get magically faster.

I don't think that's doable and it certainly shouldn't be the first goal.
Deciding which headers should go into the pch header is a manul process.

> I'm sure you care nothing for Visual C++, but most of the people begging for
> PCH support are probably coming from this world.

I'm not using automake to target VC. :p


-- 
Olaf

Message #40 received at 8076 <at> debbugs.gnu.org (full text, mbox):

From: Olaf van der Spek <ml <at> vdspek.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 8076 <at> debbugs.gnu.org, automake <at> gnu.org
Subject: Re: PCH support
Date: Fri, 23 Dec 2011 23:10:12 +0100

On Fri, Dec 23, 2011 at 5:46 PM, Stefano Lattarini
<stefano.lattarini <at> gmail.com> wrote:
> First, I know basically nothing about PCH, and it seems to me that it is not
> a feature many users would require or employ.

Why not? It can drastically reduce build times of C++ projects. I have
little experience with C projects, but I assume it speeds those up as
well.
Conceptually, it's also simple to implement (for someone with automake
knowledge).

> Second, and more important: as you can easily see, the Automake bug tracker
> is full of bug reports with higher precedence, and of feature requests with
> potentially more widespread user bases.

Do automake users not care about build times?


-- 
Olaf

Message #43 received at 8076 <at> debbugs.gnu.org (full text, mbox):

From: Russ Allbery <rra <at> stanford.edu>
To: 8076 <at> debbugs.gnu.org,  automake <at> gnu.org
Subject: Re: PCH support
Date: Fri, 23 Dec 2011 22:44:36 -0800

Olaf van der Spek <ml <at> vdspek.org> writes:

> Why not? It can drastically reduce build times of C++ projects. I have
> little experience with C projects, but I assume it speeds those up as
> well.

It's unlikely to help a great deal with most C projects, since most C
headers just aren't very complicated and other parts of the compilation
process dominate the time.  C++ is significantly different than C in how
much complexity it puts into its headers.

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.