Fix building CPython with -DWIN32_LEAN_AND_MEAN on Windows

[georgthegreat]

Feature or enhancement

Proposal:

We use customized build of CPython which compiles all the sources with -WIN32_LEAN_AND_MEAN, thus limiting the amount of transitive #include from Windows.h header.

I would like to propose a series of enhancements to make CPython buildable in this configuration.

Has this already been discussed elsewhere?

No response given

Links to previous discussion of this feature:

No response

Linked PRs

• gh-115882: Add missing #include <Unknwn.h> on Windows #115350

[zooba]

Most of these patches are likely to be innocuous, so they'll likely be merged with no problem (though not backported, as this is not a bug).

However, I'd be interested to know what benefit you get from compiling with this flag set? It has no impact on the final result, so presumably you're seeing a performance improvement in building. Is it significant?

[georgthegreat]

@zooba, it looks like it was the only patch regarding WIN32_LEAN_AND_MEAN build (though not the only patch we apply in total).

As for your question, having this CFLAG defined allows to reduce negative impact of tranisitive Windows SDK headers which tend to define various keywords as a macros (see protobuf solution for the case).

As we are using our own build system to compile both python sources and our own code, we have simply defined this CFLAG universally.

As for the guarantees from Microsoft — they do neither recommend nor discommend using this define (see here). Yet their documentation explicitly recommends including particular header instead of expecting windows.h to include it transitively.

[zooba]

Yet their documentation explicitly recommends including particular header instead of expecting windows.h

To be clear, this is not an explicit recommendation, but an acknowledgement that this is the header file that contains the definition. In many such cases, an explicit recommendation is made to include windows.h instead of the one listed, but that appears to be at the discretion of the documentation author.

Avoiding certain macros being defined is a perfectly good reason though. If this is the only one you need, glad to have been able to help.