From: Andrei Melnikov (andy.melnikov_at_[hidden])
Date: 2006-10-15 21:53:03
On 15/10/06, Vladimir Prus <ghost_at_[hidden]> wrote:
> I was thinking more about PCH support. While it can decrease compilation time
> for toolsets with PCH support, having a central header including all STL and
> all Boost, and all Windows headers will reduce compilation time when PCH is
> not available. How about making pch generators set a macro, has
> BOOST_BUILD_PCH_ENABLED, so that client code can use this:
> #if defined(BOOST_BUILD_PCH_ENABLED)
> #include "pch.h"
> Then, if toolset lacks PCH support, the pch header won't be included at all.
I like this feature. Personally, I already have this macro. I called
it STDAFX_DISABLED, so your name is rather good.
Also, last time I checked (VS2005 beta 2) some optimizations (namely
WPO) didn't work if PCH were used. So it's useful to maintain both
pch- and non-pch configurations.
However, just to note, Boost.Build still doesn't enable whole program
optimization in release builds.
Also MSVC has strange behaviour regarding the #include "pch.h"
statement. "pch.h" is just a label passed to it's /Yu switch, it's not
a usual include name reference.
I mean that #include "pch.h" isn't portable - it stops to work in some
cases at all in case of MSVC if PCH are turned off, so the whole issue
around BOOST_PCH_ENABLED isn't just about speed boost. It would also
help to create code portable between pch-on and pch-off and between
Also I wonder now other compilers support PCH - e.g. if there some
compilers using #pragma stop.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk