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

Nicodemus nicodemus at globalite.com.br
Sat Oct 11 00:16:07 CEST 2003


Niall Douglas wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On 9 Oct 2003 at 20:27, Nicodemus wrote:
>
>
>>>>Well, this headers are included always first:
>>>>
>>>><boost/python.hpp>
>>>><boost/cstdint.hpp>
>>>>
>>>Err, they're not here. The first include is always the one the 
>>>Class() or AllFromHeader() has pulled in, which is invariably not
>>>global across all modules.
>>>
>>Both in single and multiple mode. Can you post your generated code
>>where the user's headers are included first?
>>
>
><snip example that proves that the includes don't appear in any particular order>
>

Oops, again. ;)
You're completely right. I was using the new version, where this problem 
*accidentaly* goes away. Now <boost/python.hpp> and <boost/cstdint.hpp> 
are included first, and then the user includes follow, sorted by name. 
What you thing?

>Actually yes and I'd make it only permit one file only. Why? Because 
>it seems future G++ support will only permit one precompiled header 
>file per compilation. See 
>http://gcc.gnu.org/onlinedocs/gcc/Precompiled-
>Headers.html#Precompiled%20Headers
>
>Therefore in my example above, we'd need to have one header file 
>including everything common to all modules. This will require some 
>tweaking on my end (I'll do it tonight).
>

Don't know though how we could make such prohibition, because nothing 
stops the user from writing a PCHInclude in a pyste file and then 
PCHInclude again in another, and then running pyste in multiple mode 
passing only one of them. I think it's ok to let the user take care 
about that.

>>Also, I seem to have missed the point
>>of your posted #ifdef...
>>
>
>Because #pragma hdrstop won't compile on GCC.
>

Sorry, I meant the entire snippet:

#ifdef _MSC_VER
#pragma hdrstop
#endif    

Not only the #ifdef part... 8)

>>So, PCHInclude would always include that header first in *all*
>>modules, right? Anything else is needed?
>>
>
>Well, you needn't go that far as I and probably most people invoke 
>pyste once per .pyste file (not many .pyste files at once). Making 
>pyste behave differently with many files and a single file seems 
>foolish as my make system only re-pyste's the pyste files which would 
>have changed from the headers they include changing. I don't want to 
>re-pyste everything with each header file change!
>

Sorry, my phrase was (very) badly worded. I didn't meant that once Pyste 
sees a PCHInclude, it should re-generate all the other pyste files, just 
that, inside a Pyste file, the contents of PCHInclude should be included 
*first* before anything else (well, perhaps after the boost's includes?).

So, summarizing, given this Pyste file:

A = Class('A', 'A.h')
PCHInclude('stdfx.h')

The generated file:

// Boost Includes 
==============================================================
#include <boost/python.hpp>
#include <boost/cstdint.hpp>

// PCH 
=========================================================================
#include <stdfx.h>

// Includes 
====================================================================
#include <A.h>


Is enough for PCH support?

Regards,
Nicodemus.





More information about the Cplusplus-sig mailing list