[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