[CMake] CMAKE_*_IMPLICIT_INCLUDE_DIRECTORIES with MinGW

[Alan W. Irwin]

On 2018-11-08 07:36+0100 Olivier Croquette wrote:

> Hi everyone,
>
> any feedback on this?
> As a summary, it's about adding the default include paths of GCC to the 
> variables "CMAKE_*_IMPLICIT_INCLUDE_DIRECTORIES" to avoid CMake modules or 
> scripts to mess up with them, more specifically with their order.

Hi Olivier:

I am afraid I cannot help you directly with your specific question
because I have no access to the Microsoft version of Windows, and it
has been a while since I worked with the Wine version of Windows.
However, for the sake of those who might be able to help you, I
suggest you clarify exactly what you mean by "MinGW". For example,
some possibilities are

1. MinGW, the traditional gcc variant for Windows.  This platform uses
    the CMake generator "MinGW Makefiles" and the MinGW version of GNU
    make.

2. MinGW-w64, a successor (with different developers, see
    <https://sourceforge.net/p/mingw-w64/wiki2>) to MinGW.  This
    platform uses the CMake generator "MinGW Makefiles" and the
    MinGW-w64 version of GNU make (see
    <https://sourceforge.net/p/mingw-w64/wiki2/Make/>)

3. MinGW/MSYS which combines the traditional gcc variant for Windows
    and a traditional Unix-like variant for Windows where MSYS is
    developed by the same group of developers as MinGW.  This platform
    uses the CMake generator "MSYS Makefiles" and the MSYS version of
    GNU make.

4. MinGW-w64/MSYS2 a successor to MinGW/MSYS where the MSYS2
    developers are a different group (See
    <https://github.com/msys2/msys2/wiki>) than the MinGW-w64
    developers and the MSYS developers. This platform uses the CMake
    generator "MSYS Makefiles" and the MSYS2 version of GNU make.

5. A slight variant of 4. which uses the "Unix Makefiles" generator.

The reasons these platform distinctions are important for your
question is the issue you have found might not be an issue for
some/most of them.  For example, years ago I did do comprehensive
(including static linking) tests of PLplot on platform 3 for the Wine
version of Windows, and I do not recall encountering the issue you
have described.  And my friend and PLplot colleague Arjen Markus who
comprehensively tests PLplot on platform 5 on a regular basis has also
never run into this issue according to the comprehensive test reports
he has sent to me over the years including one such report just last
week.

Of course, PLplot comprehensive tests might not expose the issue you
have discovered so I suggest you provide a self-contained minimal
CMake-based project (minimal C source code + CMake build system to
build it) which demonstrates the issue you have found on at least one
of the above platforms.  Once you supply that, others here can
conveniently use that test project to verify (or not) the issue on any
of the above 4 platforms.

Good luck with your further investigations into this issue!

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________