[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