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.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
