[C++-sig] Pyste suggestion: MSVC precompiled headers support

Niall Douglas s_sourceforge at nedprod.com
Wed Oct 8 19:58:38 CEST 2003

Hash: SHA1

On 7 Oct 2003 at 23:41, Nicodemus wrote:

> >I would suggest Include() for per-file includes and CommonInclude()
> >for the cross-module includes. Then even better you can have your
> >converter registering modules (I call mine _regconvs) generate your
> >precompiled headers for you which saves another ten seconds :)
> Sorry, you will have to be a little more specific than that: I have no
> experience with precompiled headers. 8) Also, could you tell the
> compiler switch and how to create/use precompiled headers? Using just
> your code didn't improve the speed at all, and didn't generate any PCH
> file. 8(

Precompiled headers are really precompiled source ie; just before the 
back end of the compiler spits out assembler. In MSVC you must use 
special command line switches to both generate and use precompiled 
headers - without these nothing happens.

The traditional use is to tell MSVC to ignore everything prior to 
some specified header file or #pragma hdrstop ie; therefore if pyste 
puts an extra header file before that point, MSVC misses it 
completely and the file won't compile.

Because pyste doesn't order its header files in a usefully 
predictable way and order, it's very hard to set settings which 
correctly work without some hand reordering.

If you do get precompiled headers working (and once MSVC fixes the 
bugs which mean it doesn't work properly with Boost), you can expect 
up to a 50% speed increase.

To give you some idea, with a naïve MSVC project implementation it 
was taking me about three hours to compile. With scons and 
precompiled headers, it's about 35 mins. That's about five or six 
times quicker!!!

> But I am not very inclined to add a new function just to support
> precompiled headers, since they're only avaiable on windows... 8/ And,
> from the little I know, you can always generate your own pre-compiled
> header and include that in your Pyste files, right?

I think GCC has them on the way. Not in v3.3, but very soon now. So 
the new command *will* become useful.

If you could always get pyste to start off with *exactly* the same 
#include's in the same order across all modules, then we don't need 
this feature. I had been assuming that the mechanism I proposed was 
easier and better extensible for the future.


Version: idw's PGP-Frontend / 9-2003 + PGP 8.0.2


More information about the Cplusplus-sig mailing list