Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86
On 9/17/19 2:17 PM Joao Pedro Abreu De Souza wrote:
cl from visual studio 2017.
Em ter, 17 de set de 2019 03:26, Stéphane Ancelot
mailto:sance...@numalliance.com>> escreveu:
Hi,
That first depends on which compiler you will use ?
Regards,
S.Ancelot
Le 16/09/2019 à 22:32, Joao Pedro Abreu De Souza a écrit :
Hi guys. I am trying to generate,using cmake, a executable with
target Windows 32 bits using Windows 64 bits, but cannot find a
standard toolchain file (I find to Linux, to Android, but can't
find to Windows 32 bits) to build. Do you know some repository of
toolchain files that has Windows 32 bits from Windows 64 bits? Or
maybe someone has a standard toolchain file to this type of thing.
Well, I don't have a toolchain file for your compiler, but maybe my
toolchain file for cross compilation under Linux for Windows (64-bit)
can help. You'll need to adjust compiler and paths...
$ cat mingw-w64_toolchain.cmake
# CMake Toolchain File for MinGW-w64 (64-bit) Cross Compilation
# the name of the target operating system
set(CMAKE_SYSTEM_NAME Windows)
# which tools to use
set(CMAKE_C_COMPILER /usr/bin/x86_64-w64-mingw32-gcc)
set(CMAKE_CXX_COMPILER /usr/bin/x86_64-w64-mingw32-g++)
# here is where the target environment located
set(CMAKE_FIND_ROOT_PATH /usr/x86_64-w64-mingw32)
# adjust the default behavior of the FIND_XXX() commands:
# search programs in the host environment
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# search headers and libraries in the target environment
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_INSTALL_PREFIX ${CMAKE_FIND_ROOT_PATH}/usr CACHE FILEPATH
"install path prefix")
# initialize required linker flags
set(CMAKE_EXE_LINKER_FLAGS_INIT "-static-libgcc -static-libstdc++")
# end of toolchain file
HTH. YMMV
--
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:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Embedded build using ExternalProject
On 6/26/19 3:53 PM Torsten Robitzki wrote: I don’t want to build any EOL test firmware, test-tools etc. just the stuff that will be shipped, thus the explicit target. I can build the firmware_binaries, from the source directly, without problems. But when I try to build with the top-level cmake file, that contains the ExternalProject_Add(), I get the usual configure output and then: -- Configuring done -- Generating done -- Build files have been written to: /Users/todi/blueswd_firmware/build/firmware_binaries-prefix/src/firmware_binaries-build Is this a on a Windows system? Are you maybe using Cygwin or MinGW? [ 75%] Performing build step for 'firmware_binaries' [ 12%] Performing build step for 'firmware_binaries' [ 12%] Performing build step for 'firmware_binaries' [ 12%] Performing build step for ‚firmware_binaries‘ … This line repeats until make reports: make[776]: /usr/local/Cellar/cmake/3.14.3/bin/cmake: Resource temporarily unavailable make[776]: *** wait: No child processes. Stop. make[776]: *** Waiting for unfinished jobs make[776]: *** wait: No child processes. Stop. Any idea, what might be wrong here? Some kind of recursion? "Resource temporarily unavailable" looks like a well-known Cygwin (or maybe also MinGW) issue. If both of your answers above is "yes" I'd guess it is. As a workaround you may try to use 'make -j1' or something like this to reduce the number of concurrent make jobs, but this is only a guess. -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Troubles compiling llvm
Am 23.05.2019 10:40 schrieb Steven Truppe: i'm trying to compile llvm with ExternalProject_Add and get the following error: -- Installing: /usr/lib/ocaml/llvm/llvm.mli CMake Error at bindings/ocaml/llvm/cmake_install.cmake:49 (file): file INSTALL cannot copy file "/home/stuv/linux-projects/programming/bsEdit/build_files/Release/llvm/src/external_llvm-build/bindings/ocaml/llvm/llvm.mli" to "/usr/lib/ocaml/llvm/llvm.mli". Call Stack (most recent call first): bindings/ocaml/cmake_install.cmake:42 (include) cmake_install.cmake:64 (include) This sounds like you need access rights, you probably need to use: $ sudo make install (unless the file doesn't exist, but I assume this would be another error message) -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] How can I automatically optionally build a submodule?
On 12.03.2019 06:37 Steve Keller wrote: How can I build a module in a subdirectory automatically if a required package is available, but not fail if it's not. Say I have a top-level CMakeLists.txt with add_subdirectory(foo) add_subdirectory(bar) and in directory foo I have in CMakeLists.txt find_package(yadda, REQUIRED) I want the submodule foo to be build automatically if the package yadda is found. Otherwise, foo should be left out and the top-level build should not fail but continue. If you want yadda to be optional then don't use REQUIRED. find_package(yadda) if (yadda_FOUND) message(STATUS "found yadda, building bar ...") # add your code to build bar here endif () This should do what you want - unless I misunderstood your question. -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Using CMake for the first time on an established project
On 08.07.2017 15:06 timothylegg . wrote: I have CMake installed via apt-get on a few Debian-derived operating systems. My question is version independent, and I haven't checked, but I think version 2.8.0+ describes all the machines. There is a software project that I am wanting to become involved in that uses cmake, but I have never used makefiles of any sort within the last 20 years. I have a vague understanding of how they function and what their goals are, it's just that I've never written anything that had a level of complexity to require it. First thing to know here is that CMake is not another kind of make. It's a build system generator that can - among others - generate Makefiles for you to run 'make' to build your project. So lets get to the specifics, the project is open62541.org. Somebody wrote a wonderful PDF tutorial (link below) that suggests that compilation flags, such as BUILD_SHARED_LIBS, UA_ENABLE_METHODCALLS, or UA_ENABLE_AMALGAMATION, but fails to explain exactly how they are enabled. Would these be passed as parameters to cmake or would they have to be inserted into a file that the CMake tool suite expects to find upon execution of cmake? These are CMake options (aka "cache variables") that can either be specified on the cmake command line [1] or changed later in one of the GUI tools that come with CMake. On page 7 in the mentioned PDF file you can see (for Linux builds): # select additional features ccmake .. make So you need ccmake to be installed with cmake. On Ubuntu the package name is "cmake-curses-gui", so if you can't run 'ccmake' you need to install this. Another option is mentioned under the "Windows" section in the tutorial, but this is also availabel under Linux: cmake-gui (Ubuntu package name: "cmake-qt-gui"). Once you launch one of these GUI tools (after running the initial 'cmake' command, but optionally before 'make' you'll see the mentioned CMake options/variables and can change them interactively. After changing variables, be sure to run 'configure' and 'generate' within cmake-gui or ccmake. Then, exit the GUI and run 'make'. [1] to specify CMake options on the command line use this syntax: cmake -D"OPTION=value" -D"OTHER_OPTION=other_value" .. -- 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
Re: [CMake] Adding Cmake version in online documentation
On 11.11.2016 22:36 Alexander Neundorf wrote: On Wednesday 09 November 2016 09:22:24 Nils Gladitz wrote: ... Policy warnings are intended to encourage you to switch to new behaviours since the old ones are deprecated. In actively maintained projects they are not meant to be suppressed. I heard that argumentation several times, and still don't agree. "actively maintained" doesn't automatically mean to always require the newest versions of everything, see the mail from Albrecht Schlosser (FLTK) or how CMake requirements were handled during the KDE4 era. To make the software buildable on as many as possible systems, it helps to not to require new versions of any needed tools or libraries. So, Albrecht can absolutely actively maintain FLTK, and at the same time decide to require a relatively old cmake version (Ok, 2.6 is ancient). I absolutely agree. (Surprise, surprise.) ;-) Thanks for supporting my arguments. As long as he doesn't plan to update the required version for cmake, I would suppress all policy warnings about new behaviour. Is it guaranteed that changing the code so that the warning, which appeared e.g. in cmake 3.4, is fixed, still works correctly with the old, required version of cmake ? I think no. Particularly not if you set any policy to NEW. I don't think that this is a valid setting because it would give different behaviour on older (pre-this-new-behaviour/policy version) and later versions. I can't think of a real usage case of any policy setting to NEW. Unless your code is conditional depending on the CMake version. Once there is a plan to upgrade the cmake version, the warnings become useful, but IMO not before. Nitpicking: should read "... upgrade the *required* cmake version ...". This free library case (FLTK) where the public is addressed with the least restrictions is different than a (maybe commercial) project where you can dictate the required versions and can control the build environment. -- 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
Re: [CMake] Adding Cmake version in online documentation
On 11.11.2016 22:36 Alexander Neundorf wrote: You could have a look at the major distributions and what they ship. Thanks for your comments. We do not only want to support the major distributions but also (maybe proprietary) cross compilation tools. That's why we still support autoconf/configure as well. The oldest I have to support is RHEL 5, released first 2007, and that feels really ancient. But there are people out there which still run such systems. Centos 5 comes with CMake 2.6.4, Centos 6 with 2.8.12. OTOH, installing additional versions of CMake is really easy, thanks to the binary packages provided by Kitware (... which IIRC are built in a Docker Centos 5 container). Even compilation of CMake is pretty easy. Thanks to its 'bootstrap' mode. Btw. I really appreciate your idea to keep the requirements low. :-) You're welcome. See above why this is so essential for FLTK. You can have a look here, there is the documentation for all cmake versions back to 2.6: https://cmake.org/documentation/ Thanks for the link as well. I forgot about that because I was mostly searching with g**le and that seems to find random versions... Alex Albrecht -- 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
Re: [CMake] Adding Cmake version in online documentation
On 08.11.2016 23:01 Nils Gladitz wrote: On 08.11.2016 20:26, Albrecht Schlosser wrote: I'm a developer of a public GUI library (FLTK). In this position you don't know anything about the availability of CMake versions on your target platforms. Our intention is to keep cmake_minimum_required() as low as possible. If you are intending to keep the required version as low as possible you'll already have a justification / reason for doing so. I can only assume that the reason is that you need to support ancient platforms which ship equally ancient versions of CMake and you don't want to bother your users to build or install custom newer versions of CMake. It doesn't matter what your reasons or justifications for it are (though I would hope they are valid and verified) but you have to decide on a minimum version that you can life with in the end. Basically that's a floating target. We need to evaluate this from time to time and maybe adjust the required version. That said, whenever you change a CMakeLists.txt file you should be aware if the commands you use are compatible with the CMake version you "require". There should be an easy way to find out in which version a particular CMake command has been introduced. Only with this information you can decide if you should use this fine command or better find another way to do the task you're going to do. At this point you only have to refer to the documentation that actually corresponds to the version you decided to require. You'll only find commands and behaviours in that documentation that'll actually be available in your minimum version. Yep, that's simple, of course. But if there is a (new) command you want to use it would be interesting to know the CMake version it was introduced to _decide_ if you can or want to do without it or raise the required version. I'm sure that we will raise the required version when CMake gets (or got) a new feature we need to use. But we need the facts to decide... I'd like to have a list of release dates (I'm not sure if there is one) as well as the exact version a feature was introduced to write CMakeLists.txt files that run on really old CMake versions. I think the git tag creation dates should roughly equate release dates: https://cmake.org/gitweb?p=cmake.git;a=tags Thanks for this, I appreciate your help. Note: currently we have cmake_minimum_required(VERSION 2.6.3) (sic!), but we also have conditional code for some higher CMake versions: 2.6.3's tag e.g. "Sat, 21 Feb 2009 19:43:45 + (14:43 -0500)" would be over 7 years old now. As I said: this is a floating target. Since this version is so old we may decide to require a more recent version in the near future, but likely not yet 3.7 ;-) if(CMAKE_VERSION VERSION_GREATER 2.8.4) ... if(NOT CMAKE_VERSION VERSION_LESS 3.0.0) ... There are exceptions to every rule but I'd personally avoid or at least try to minimize such constructs if possible. I think these two are the only special cases, and they are used for new features we use if available with a fallback (or not at all) if the CMake version is older. CMake's policy mechanism tries hard to preserve old behaviours so that existing projects depending on those old behaviours don't break with new versions of CMake. Given your minimum required version CMake 3.7 will still mostly try to behave like 2.6.3. I'm not very familiar with CMake policies. Maybe I need some more RTFM. With constructs like these this is no longer the case and you need an increasing number of CMake versions to get proper coverage. Developers that use one specific version of CMake can not longer be reasonably confident that their CMake script changes also work on other versions of CMake covered by distinct version specific conditionals. Good point, thanks for this as well. But as I said before, these constructs are only exceptions. BTW: Thanks to all CMake devs for this great tool! -- 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
Re: [CMake] Adding Cmake version in online documentation
On 08.11.2016 22:23 Eric Noulard wrote: 2016-11-08 20:26 GMT+01:00 Albrecht Schlosser <...>: I'd also like such an addition to the documentation for reasons discussed below. I think the need is recognized by most CMake user but... okay... Strictly speaking cmake_minimum_required(VERSION) is not about command availability but rather about behavior (cmake policies). [...] I'd start by requesting the highest possible version I could justify (e.g. based on availability on target platforms and user convenience) and then start from there. And that's exactly the (my) point. How can I find out the "highest possible version I could justify"? I'm a developer of a public GUI library (FLTK). In this position you don't know anything about the availability of CMake versions on your target platforms. Our intention is to keep cmake_minimum_required() as low as possible. That said, whenever you change a CMakeLists.txt file you should be aware if the commands you use are compatible with the CMake version you "require". There should be an easy way to find out in which version a particular CMake command has been introduced. Only with this information you can decide if you should use this fine command or better find another way to do the task you're going to do. I'd like to have a list of release dates (I'm not sure if there is one) as well as the exact version a feature was introduced to write CMakeLists.txt files that run on really old CMake versions Some time ago people came up (dig the ML for the related discussion) with compatibility matrix idea: https://cmake.org/Wiki/CMake_Version_Compatibility_Matrix http://public.kitware.com/pipermail/cmake/2010-December/041202.html And it finally ends with cmake 3.0.0 http://public.kitware.com/pipermail/cmake/2015-March/059983.html Note that this is far more complicated than simply listing when one command appears because some command may get more options, or change their default semantic (using POLICY etc..) so the feature granularity leads to question like When did the 'string' cmake command support the UUID argument ? Before which version of CMake does get_target_property accept non-existent target argument without issuing any error or warning ? (see POLICY CMP0045) So basically, tracking all kind of behavior change is not as easy as it seems. Sure, I agree. Thanks for your elaborate comments. How can we document the changes ? Or better extract them from the code or documentation? A simple comment like "since 3.5.0" for the _first_ appearance of a command would be very helpful. Added keywords could be commented as well. I see that behavior changes would be more difficult to document, but documentation of policies seem to do a good job in their particular cases. -- 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
Re: [CMake] Adding Cmake version in online documentation
On 08.11.2016 15:22 Nils Gladitz wrote: On 11/08/2016 03:11 PM, Dvir Yitzchaki wrote: But how do you know which version to declare on cmake_minimum_required? If this feature will be added it won't be far from writing a script that scans the commands you use and outputs the first appropriate version. I'd also like such an addition to the documentation for reasons discussed below. Strictly speaking cmake_minimum_required(VERSION) is not about command availability but rather about behavior (cmake policies). [...] I'd start by requesting the highest possible version I could justify (e.g. based on availability on target platforms and user convenience) and then start from there. And that's exactly the (my) point. How can I find out the "highest possible version I could justify"? I'm a developer of a public GUI library (FLTK). In this position you don't know anything about the availability of CMake versions on your target platforms. Our intention is to keep cmake_minimum_required() as low as possible. That said, whenever you change a CMakeLists.txt file you should be aware if the commands you use are compatible with the CMake version you "require". There should be an easy way to find out in which version a particular CMake command has been introduced. Only with this information you can decide if you should use this fine command or better find another way to do the task you're going to do. I'd like to have a list of release dates (I'm not sure if there is one) as well as the exact version a feature was introduced to write CMakeLists.txt files that run on really old CMake versions. Note: currently we have cmake_minimum_required(VERSION 2.6.3) (sic!), but we also have conditional code for some higher CMake versions: if(CMAKE_VERSION VERSION_GREATER 2.8.4) ... if(NOT CMAKE_VERSION VERSION_LESS 3.0.0) ... I'd appreciate such additions very much to be able to write more portable CMake files. TIA. -- 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
Re: [CMake] Wrong version of cl.exe for x64
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
[CMake] Visual Studio generator does not find some header files
I found an inconsistency when executing CMake directly from a desktop
link vs. running it for instance from a "Developer Command Prompt for
VS2015" _or_ executing CMake's (re)configure stage from within the
Visual Studio environment after modifying one of the CMake files.
This seems to indicate that "something" is not set up correctly if I
execute CMake directly (clicking the desktop link or running it from the
Windows Explorer).
On 22.08.2016 12:54 Nils Gladitz wrote in another thread:
> 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.
The following example CMakeLists.txt file seems to indicate that this is
not true, at least for CMake 3.2.1. I'm currently not keen on installing
another (newer) CMake version, but if this is fixed in a newer version I
can do this.
System: Windows 10
Visual Studio 2015 Community 2015, Update 3
CMake 3.2.1
Here is my minimal CMakeLists.txt that is needed to run the configure
step and show the results. Note that "other" header files are found w/o
issues.
I can provide more (with a configure_file) if requested.
#-
# CMakeLists.txt
#-
cmake_minimum_required(VERSION 2.8)
project (find_headers)
find_file (HAVE_GL_GL_H GL/gl.h)
find_file (HAVE_GL_GLU_H GL/glu.h)
find_file (HAVE_LOCALE_H locale.h)
if (MSVC)
message(STATUS "Note: The following three headers should all be found!")
message(STATUS "HAVE_GL_GL_H = '${HAVE_GL_GL_H}'")
message(STATUS "HAVE_GL_GLU_H = '${HAVE_GL_GLU_H}'")
message(STATUS "HAVE_LOCALE_H = '${HAVE_LOCALE_H}'")
message(STATUS "If one of these headers was not found, run cmake-gui
...")
message(STATUS "... again from a Visual Studio developer command
prompt!")
endif (MSVC)
#-
# End of CMakeLists.txt
#-
# Run cmake-gui directly by clicking the installed desktop link
# to the cmake-gui executable
# Click 'configure'
The C compiler identification is MSVC 19.0.24213.1
The CXX compiler identification is MSVC 19.0.24213.1
Check for working C compiler using: Visual Studio 14 2015 Win64
Check for working C compiler using: Visual Studio 14 2015 Win64 -- works
Detecting C compiler ABI info
Detecting C compiler ABI info - done
Check for working CXX compiler using: Visual Studio 14 2015 Win64
Check for working CXX compiler using: Visual Studio 14 2015 Win64 -- works
Detecting CXX compiler ABI info
Detecting CXX compiler ABI info - done
Detecting CXX compile features
Detecting CXX compile features - done
Note: The following three headers should all be found!
HAVE_GL_GL_H = 'HAVE_GL_GL_H-NOTFOUND'
HAVE_GL_GLU_H = 'HAVE_GL_GLU_H-NOTFOUND'
HAVE_LOCALE_H = 'HAVE_LOCALE_H-NOTFOUND'
If one of these headers was not found, run cmake-gui ...
... again from a Visual Studio developer command prompt!
Configuring done
# Repeating configure ...
Note: The following three headers should all be found!
HAVE_GL_GL_H = 'HAVE_GL_GL_H-NOTFOUND'
HAVE_GL_GLU_H = 'HAVE_GL_GLU_H-NOTFOUND'
HAVE_LOCALE_H = 'HAVE_LOCALE_H-NOTFOUND'
If one of these headers was not found, run cmake-gui ...
... again from a Visual Studio developer command prompt!
Configuring done
# Now executing "Developer Command Prompt for VS2015"
C:\Program Files (x86)\Microsoft Visual Studio
14.0>c:\CMake\bin\cmake.exe --version
cmake version 3.2.1
CMake suite maintained and supported by Kitware (kitware.com/cmake).
C:\Program Files (x86)\Microsoft Visual Studio
14.0>c:\CMake\bin\cmake-gui.exe
# Clicking 'configure' in the same build directory configured before:
Note: The following three headers should all be found!
HAVE_GL_GL_H = 'C:/Program Files (x86)/Windows Kits/8.1/Include/um/GL/gl.h'
HAVE_GL_GLU_H = 'C:/Program Files (x86)/Windows
Kits/8.1/Include/um/GL/glu.h'
HAVE_LOCALE_H = 'C:/Program Files (x86)/Windows
Kits/10/Include/10.0.10240.0/ucrt/locale.h'
If one of these headers was not found, run cmake-gui ...
... again from a Visual Studio developer command prompt!
Configuring done
# End of log
As you can see, CMake finds the above mentioned headers when
executed from a "Developer Command Prompt for VS2015", but not
when executed directly by clicking the CMake desktop link or
clicking cmake-gui in the windows explorer.
Further tests show that CMake also finds the headers when it needs to
reconfigure something within the VS IDE because a CMake file was changed.
Wild guess: given the paths of the header files in question I assume
that it has something to do with the SDK files ('Windows
Kits/8.1/Include/um/GL/...' and 'Windows
Kits/10/Include/10.0.10240.0/ucrt/...'
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
Re: [CMake] Wrong version of cl.exe for x64
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. -- 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
Re: [CMake] Wrong version of cl.exe for x64
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? ;-) I know of a case where running CMake (3.2.1) from the installed desktop link does not find some headers that are found if I run CMake from within a "Developer Command Prompt for VS2015". Note: I did not use vcvarsall.bat explicitly. Shall I post an example CMake file? -- 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
Re: [CMake] arguments for EXECUTE_PROCESS
On 27.01.2016 23:05 Fabian Wein wrote:
For my a test suite I want to test a Python script,
I have the arguments in a variable like
SET(MATVIZ_ARGS „—res 2 —type bulk2d’")
and call it similar to
EXECUTE_PROCESS(
COMMAND "${MATVIZ_PY}" "${MATVIZ_ARGS}"
Suggestion: do not quote the argument variable here:
COMMAND "${MATVIZ_PY}" ${MATVIZ_ARGS}
WORKING_DIRECTORY "${CCSD}"
ERROR_VARIABLE MATVIZ_ERROR
RESULT_VARIABLE MATVIZ_RETVAL
)
or do something like this:
SET(MATVIZ_ARGS "—res 2" "—type bulk2d")
EXECUTE_PROCESS(
COMMAND "${MATVIZ_PY}" ${MATVIZ_ARGS}
...
If you need arguments with spaces, you might have to double quote the
arguments in the SET command.
--
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
