[CMake] Wrong version of cl.exe for x64

Albrecht Schlosser AlbrechtS.fltk at online.de
Mon Aug 22 13:34:22 EDT 2016


On 22.08.2016 14:12 Nils Gladitz wrote:
> On 08/22/2016 01:30 PM, Albrecht Schlosser wrote:
>
>> On 22.08.2016 12:54 Nils Gladitz wrote:
>>> On 08/22/2016 12:18 PM, Albrecht Schlosser wrote:
>>>
>>>> On 22.08.2016 10:33 Nils Gladitz wrote:
>>>>
>>>>> The visual studio command line environments should have no effect when
>>>>> using the visual studio generators.
>>>>
>>>> Are you sure? Or what does "should" mean here? ;-)
>>>
>>> Yes. The Visual Studio generators are meant to work outside of the
>>> visual studio command line environments while the command line
>>> generators (makefiles, ninja) are meant to work from within the visual
>>> studio command line environment.
>>>
>>> What that means is that the Visual Studio generators must work
>>> without it.
>>
>> Okay, I posted a simple example CMake file to show what happens in my
>> case. See new thread:
>>
>> "Visual Studio generator does not find some header files"
>>
>> Basically some special (SDK?) header files are not found when
>> executing CMake w/o the Visual Studio environment.
>>
>
> E.g. CMake find_path() uses the INCLUDE environment variable (which is
> provided by the visual studio command line environment) if set.
>
> So yes this can influence CMake itself but not Visual Studio.
> Since the paths in the INCLUDE environment variable are not used by
> Visual Studio this can result in obvious conflicts.

Okay, I see.

> Since CMake does not (I don't know if it (easily) could) know the
> implicit include directories Visual Studio uses it can not use them in
> find_*() calls either.

Understood. Thanks for the information.

> In case of the OpenGL library (which on windows is part of the
> windows/platform SDK) cmake e.g. assumes (within the FindOpenGL.cmake
> module) that the header is in an implicit include directory and does not
> try to locate it.

Well, that's a pity. This makes it necessary to use platform specific 
code in CMake files unless you can completely rely on modules that do 
already include such platform specify code.

> Assuming this matches your use case I would suggest you do the same.

Indeed our case in FLTK (www.fltk.org), a cross platform GUI library 
(for those that don't know it) is related to OpenGL (GL/gl.h and 
GL/glu.h), but also locale.h. We need to know if we can #include these 
(and other) header files in the library code.

I took a look into our old bundled IDE files and found that we _assumed_ 
that these headers existed even in our oldest supported Visual C++ IDE 
(the provided config.h file was edited accordingly).

So, the conclusion is: since CMake can't figure it out we have to 
_assume_ that the header files can be #included in MSVC projects (MinGW 
works well), hence we should set the corresponding CMake variable to 
true, maybe something like:

if (MSVC)
   set (HAVE_GL_GL_H 1)
endif (MSVC)

Is this what you suggest?

This would work, but it's very unfortunate to have to do this. It would 
be much better if find_file() or find_path() would be able to work 
really cross platform w/o special assumptions. But I see your point.


I'll take another look in our CMake files to see if find_package(OpenGL) 
would get us to
a better solution.

Thanks for your support.



More information about the CMake mailing list