CMake build on Windows

[Rob McDonald]

I'm attempting to build FLTK 1.3.4-1 with Visual Studio 2010 on Windows 7 using CMake to build the build files.  I end up with one error (repeated many times) in flstring.h.

fatal error C1083: Cannot open include file: 'strings.h': No such file or directory

Is there a config option I'm missing?  Is one of CMake's tests failing?  Any suggestions?

Rob

[Albrecht Schlosser]

On 10.12.2016 21:42 Rob McDonald wrote:
> I'm attempting to build FLTK 1.3.4-1 with Visual Studio 2010 on Windows
> 7 using CMake to build the build files. I end up with one error
> (repeated many times) in flstring.h.
>
> fatal error C1083: Cannot open include file: 'strings.h': No such file
> or directory

First of all: I just checked FLTK 1.3.4 with CMake and Visual Studio
2015 Community and everything worked well (except the known compiler
warnings which can be ignored or suppressed).

> Is there a config option I'm missing?

There's no config option that would allow you to change that.

> Is one of CMake's tests failing?

Looks so. Please check the generated config.h, it should contain:

/* #undef HAVE_STRINGS_H */

If you have instead:

#define HAVE_STRINGS_H 1

then you may change this as a workaround for a first build success
(maybe), but that would not be a real solution. See below...

> Any suggestions?

CMake can fail finding header files etc. (false positives or false
negatives, both is possible) if it is executed with a wrong environment
so that it can find header files that belong to MinGW, Cygwin, or any
other installed software.

You can find out which header was found if you check the CMake cache,
either by running cmake-gui or opening CMakeCache.txt in the build
directory with an editor or some other tool (maybe grep?). If you use
cmake-gui, check the "Advanced" check box and search for HAVE_STRINGS_H.
If it was found it should contain the file path which could help to find
the culprit. For instance, in my Linux build I have:

HAVE_STRINGS_H:FILEPATH=/usr/include/strings.h

How did you run CMake? The recommended way is to run cmake-gui from a
"Visual Studio Developer Command Prompt" window.

If you have additional software like MinGW, Cygwin, or something else
installed I suggest that you check the environment (Windows: command
'env') and particularly the PATH variable.

Please let us know what you found out, that's interesting for our build
instructions.

[Fabien Costantini]

As you are using VS2010, did you simply try to use the already generated visual 2010 project in the:

    .\ide\VisualC2010 

subdirectory under the root ?

-Fabien

---

From: Rob McDonald <rob.a.m...@gmail.com>
To: fltk.general <fltkg...@googlegroups.com>
Sent: Saturday, December 10, 2016 2:42 PM
Subject: [fltk.general] CMake build on Windows

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rob McDonald]

Albrecht,

Sorry for the long delay in getting back to you.  It slipped through the cracks -- then the holidays, etc.

I am running the CMake build in a somewhat unusual way -- as an ExternalProject_Add embedded in my larger project.  It should be equivalent to running CMake from the command line.

The CMakeCache.txt does indeed show HAVE_STRINGS_H:FILEPATH=C:/MinGW/include/strings.h

The MinGW install was not intentional -- it was a side effect of installing Git on this machine.

My ExternalProject_Add recipe can be found here:

https://github.com/ramcdona/OpenVSP/blob/Next/Libraries/cmake/External_FLTK.cmake

I have had to carry my own patches in the past to get things to build on various platforms, so there are some remnants from that commented in the file.  The hope is to use a 1.3.4-1 with as few tweaks and changes as possible.

I believe I can either force HAVE_STRINGS_H=0 or somehow get get CMake to ignore the MinGW headers.  It seems odd that when using MSVC it would find the MInGW stuff as a solution...

Rob