[cairo] cairomm: Visual Studio WIN32 define clash with Surface::Type::WIN32

[Petr Kobalíček]

You can do that with #pragma push_macro() / pop_macro(), see:

  https://docs.microsoft.com/en-us/cpp/preprocessor/push-macro?view=msvc-160

I think that compatibility with various libraries and build systems is
always a greater deal than opinions about what's right or wrong. The
problem can be fixed by introducing a synonym to WIN32 (name already
proposed) together with still providing the old WIN32 name guarded by
push_macro() / pop_macro() - that way no project would break and new
projects can start using the new symbol instead.


On Wed, Jan 6, 2021 at 4:56 PM Francesco Pretto <ceztko at gmail.com> wrote:

> Hello James. I reply below.
>
> On Wed, 6 Jan 2021 at 16:05, James K. Lowden <jklowden at schemamania.org>
> wrote:
>
>> On Wed, 6 Jan 2021 11:05:24 +0100
>>
>> The best solution ISTM is to add
>>
>>         #undef WIN32
>>
>> somewhere early in the Cairo header files, and document it
>> accordingly.  Short of that, document it only, and caveat emptor.
>> Developers should minimize use of the preprocessor, and definitely
>> not define macros that don't need to be defined!
>>
>>
> I just tried a quick "hello world" program and this does not seem to work
> to me, or it doesn't
> seems to be a viable solution, unless you point me how it is supposed to
> work. I show what you what I tried:
> -----------------------
> #ifdef WIN32
> #undef WIN32
> #define WIN32_WAS_SET
> #endif
>
> enum class TestEnum
> {
>     WIN32
> };
>
> #ifdef WIN32_WAS_SET
> #define WIN32 1
> #endif
>
> int main()
> {
>     TestEnum enm = TestEnum::WIN32; // Doesn't compile anyway in VS2019
>     return 0;
> }
> -----------------------
>
> Re-defining WIN32 if it was found defined is a must, because it would be
> bullying, if not "criminal", to just undef it, potentially breaking outer
> software that legitimately use it.
> Is there a way to escape the TestEnum::WIN32 identifier in C++ in this
> case? Consider that I'd prefer to not use odd solutions, but still show me
> what you suggested.
>
> >  or read the words of the project maintainer Brad King[3].
>>
>> As I read his words, he was asking for the nonexistent, namely official
>> Microsoft documentation for WIN32.  Four years ago he said that 14
>> years prior CMake had defined WIN32 because "the project ... wanted it
>> defined". Two decades ago, that was common practice.  No need to
>> promulgate it further today.
>>
>>
> When the implications are very small (and I think we are in this domain) I
> think that library developers should be pragmatic and not waste their
> resources in fighting against windmills. WIN32 is still defined today in
> all default projects in latest VS 2019, and all projects generated by the
> latest CMake version. Unless there is a 100% working solution that keeps
> the WIN32 identifier and that doesn't possibly break any correct use of the
> WIN32 macro, as defined by the SDK, the build system or the user, the wiser
> choice would be to just assume WIN32 is a reserved word when compiling
> under Visual Studio.
>
> Regards,
> Francesco
> --
> cairo mailing list
> cairo at cairographics.org
> https://lists.cairographics.org/mailman/listinfo/cairo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cairographics.org/archives/cairo/attachments/20210106/9adf1b24/attachment.htm>