undef STRICT macro which breaks libproj headers

Without this I get a lot of errors like

In file included from /mnt/VTK-9.2.2/ThirdParty/libproj/vtklibproj/include/proj/io.hpp:41,
                 from /mnt/build/ThirdParty/libproj/vtk_libproj.h:41,
                 from /mnt/VTK-9.2.2/IO/NetCDF/vtkNetCDFCFWriter.cxx:34:
/mnt/VTK-9.2.2/ThirdParty/libproj/vtklibproj/include/proj/util.hpp:361:15: error: expected identifier before ',' token
  361 |         STRICT,
      |               ^
/mnt/VTK-9.2.2/ThirdParty/libproj/vtklibproj/include/proj/util.hpp:381:59: error: expected unqualified-id at end of input
  381 |                    Criterion criterion = Criterion::STRICT,
      |                                                           ^
/mnt/VTK-9.2.2/ThirdParty/libproj/vtklibproj/include/proj/util.hpp:389:78: error: expected unqualified-id at end of input
  389 |             const IComparable *other, Criterion criterion = Criterion::STRICT,
      |                                                                              ^

from multiple header files of libproj.

My setup is a Ubuntu 20.04 docker container with GCC 12.2 and MinGW 10.0.

---

Backport: paraview/release
Backport: release

Warnings:

• please consider adding a changelog entry in a file ending with .md in Documentation/release/dev.

The warnings do not need to be fixed, but it is recommended to do so.

changed the description

mentioned in issue #18449 (closed)

@ben.boeckel

What is including windows.h here? Some other things to note while looking at this:

• Why doesn't CI see this?
• The IO/NetCDF/vtkNetCDFCFWriter.cxx file lacks a copyright header (@danlipsa)

@ben.boeckel I'll add the copyright header with my next MR.

added 1 commit

• 53ef46ba - more general workaround for windows STRICT macro

Compare with previous version

Warnings:

• please consider adding a changelog entry in a file ending with .md in Documentation/release/dev.

The warnings do not need to be fixed, but it is recommended to do so.

See also !8659 (closed) and a fix from upstream: https://github.com/OSGeo/PROJ/pull/2949

Though this doesn't help with external proj, so this might still be needed.

added 1 commit

• 8ac5c1e6 - detect user defined macro STRICT without its workaround value STRICT

Compare with previous version

Errors:

• commit 8ac5c1e6 is not allowed because the following files are not formatted according to the 'clang-format' check: Common/Core/vtkWin32Header.h. Post a comment ending in the line Do: reformat to rewrite the MR source branch automatically.

Warnings:

• please consider adding a changelog entry in a file ending with .md in Documentation/release/dev.

The warnings do not need to be fixed, but it is recommended to do so.

Please rewrite commits to fix the errors listed above (adding fixup commits will not resolve the errors) and force-push the branch again to update the merge request.

Do: reformat

This topic has been reformatted and pushed; please fetch from the source repository and reset your local branch to continue with further development on the reformatted commits.

added 1 commit

• d2e4634a - detect user defined macro STRICT without its workaround value STRICT

Compare with previous version

Warnings:

• please consider adding a changelog entry in a file ending with .md in Documentation/release/dev.

The warnings do not need to be fixed, but it is recommended to do so.

Fails to build on Windows https://open.cdash.org/viewBuildError.php?buildid=8436168

added 2 commits

• ea2f97de - refactor patch to work with C++11
• 427f7e7c - add release note

Compare with previous version

resolved all threads

Do: test

Okay, it looks like my guess from !9615 (comment 1260168) that Microsoft defines STRICT by default, with the value STRICT was wrong. The CI triggers my Test on Visual Studio.

I don't understand why the CI hasn't run into the same problem so far as my build with MinGW. Maybe the corresponding headers are not included due to some include switches in the CI build?

My test does what it is supposed to. However, the current solution would in principle require the user to define the STRICT macro himself. Bad solution.

I would extend the test tomorrow so that in case of an empty defined STRICT macro it does a suitable re-define. That should work for the vast majority of cases.