[C++-sig] Pyste suggestion: MSVC precompiled headers support
Niall Douglas
s_sourceforge at nedprod.com
Wed Oct 8 19:58:38 CEST 2003
-----BEGIN PGP SIGNED MESSAGE-----
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.
Cheers,
Niall
-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2
iQA/AwUBP4RQT8EcvDLFGKbPEQLnSACfVrmKuIQ9Q+qmBfp3F8Msu9oyiuUAnjNs
G5mDoXr8i6FsstlrKkbOJI81
=laOA
-----END PGP SIGNATURE-----
More information about the Cplusplus-sig
mailing list