Re: [CMake] VS2019 LLVM Toolset?
On Thu, 24 Oct 2019 at 21:36, Osman Zakir wrote: > > Yes, I looked at this: > https://devblogs.microsoft.com/cppblog/clang-llvm-support-in-visual-studio/ > so I kind of get it. VS2019 has built-in support for LLVM. I of course do > have LLVM installed. So for this, I have to put "ClangCL" as the argument to > -T? Okay, thanks. I'll try that. The relevant part is only the first screenshot. Please note that Visual Studio 2019 also has some kind of "native support for CMake", so you don't even need to run CMake manually to generate the project. You just open a folder with CMakeLists and generate projects on the fly with whichever toolset you prefer. I was playing with it a while back with a Preview version, but it kept crashing too often to be useful. They have released a few updates since, but I never tested again, so I'm not sure if it got better or not (I hope it did), I simply keep using the traditional way for now. Mojca -- 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] VS2019 LLVM Toolset?
On Thu, 24 Oct 2019 at 20:28, Osman Zakir wrote: > > Hi. I tried to specify the LLVM Toolset for VS2019 by doing "-T LLVM" and > also "-T llvm" but it failed both times. For me "-T ClangCL" seems to have worked (provided that you install Clang with VS 2019, of course). (To figure out the potentially correct value I looked into the xml project file generated when I manually changed the toolset and saved the project.) Under 2017 this was a separate "plugin" (or whatever it was called), while VS 2019 provides it natively. What I could not get working correctly under this CMake-generated setup are the unit tests for CUDA (there must be some faulty compiler flags). Mojca -- 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] Ways to require CUDA arch minimum version?
On Fri, 16 Aug 2019 at 03:34, Hong Xu wrote: > > Is there a way to enforce a minimum CUDA arch version when finding CUDA? > Hong I don't know if the following is the correct advice, but I use the following code in my setup to enforce Pascal: string(APPEND CMAKE_CUDA_FLAGS " -gencode arch=compute_60,code=sm_60") else my code would not compile once I started using some newer directives. I believe that more archs would be needed in the string for better support of newer architectures, but just to get the starting point. I would have preferred if there was a better directive, similar to set(CMAKE_CXX_STANDARD 14) that can enable either C++14 or C++17 or later (depending on other components of the project) without actually harcoding c++14 and ending up with "-std=c++14 -std=c++20" in flags. For example something along the lines of set(CMAKE_CUDA_MIN_ARCH 60) Mojca -- 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] Does enable_language(CUDA) still have the problem with reconfiguring?
On Mon, 1 Apr 2019 at 22:11, Robert Maynard via CMake wrote: > > For MSBuild we rely on the CUDA extensions written by nvidia which do > proper dependency tracking. Except when they don't. It drove me nearly crazy that any given trivial change had to be followed by a complete rebuild of the project. But I see that someone commented an hour ago: https://stackoverflow.com/questions/48183845/visual-studio-2017-not-detecting-change-in-cu-cuda-files saying that the fix has finally arrived (in March). Mojca -- 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
[CMake] Specifying both native and cross compiler at the same time
Hi, I would like a build setup for a project to work correctly for both native and cross compilation, however one part requires native compilation and execution of the binary to generate some data tables as part of the build process (the temporary native binary is then discarded / not installed). What I seem to be unable to figure out is how to specify the compiler(s) and flags separately for the native and cross compiler. I want them to be specified by the user or package manager rather than the author of cmake files. One particular problem is when cross-compiling on mac with mingw (gcc) while using clang as the native compiler (the two compilers have incompatible flags). How can I specify two sets of compilers and flags at configure time? (The same question puzzles me in autoconf world as well. Please don't say that the native compiler should be found automatically as I really need to specify which one to use, ancient systems don't have support for C++11 with the default compiler etc.) Thank you very much, Mojca -- 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] CMake update for older PPC7
On 23 June 2018 at 17:45, Gregor Jasny via CMake wrote: > > 2) Compile it yourself. CMake is self-contained so compilation should be > relatively easy. Please note that latest versions depend on a C++11 > compatible toolchain. There is a boostrap script to compile CMake > without CMake and break the dependency cycle. Speaking of dependency cycles ... we do have quite a bit of troubles with CMake on a package manager on legacy Mac OS X platforms. C++11 means that one needs a recent and decent compiler, but the latest clang and libc++ both require CMake to be built. There are some workarounds that require building several versions of clang (I think it's all of clang 3.3, 3.4, 3,7 and then the latest one; libc++ has not been updated yet just because nobody dares to touch it, to a big part due to dependency on CMake) just for the sake of avoiding dependency cycles, but all on all this is quite a painful situation for older OSes (where older in principle means older than 10.9 or 10.7, even though compilation on 10.7 is also horribly broken on itself). Yes, gcc would be an alternative to build CMake which does not depend on CMake itself, but then we end up mixing different stdlibs and Apple is avoiding GPL 3 like a plague (packages for llvm/clang are maintained by an Apple employee). Mojca -- 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] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to combine?
On 9 February 2018 at 18:24, Alan W. Irwin wrote: > On 2018-02-09 10:44- Arjen Markus wrote: > >> Hi Alan, >> >> The result is the same or very much the same. > > OK. Time for more knowledgable people to weigh in here about what > Platform filenames to use for the combination of nagfor and > MinGW-w64/MSYS2 for the "Unix Makefiles" and "MSYS Makefiles" > generators. > > Meanwhile, can you test whether the Platform filename I suggested for > the nagfor Cygwin case with "Unix Makefiles" generator is correct? > > Alan I wonder if this is in any way related to https://cmake.org/Bug/view.php?id=14252 We had numerous problems with Fortran flags simply inheriting settings from CFLAGS under assumption that the Fortran compiler must be "the same" as C complier and probably understand the same flags. Our most burning issue was resolved once GCC's Fortran stopped complaining about "-arch", but the underlying problem in CMake was probably never resolved. We were also not able to prevent the use of Fortran in case it was detected on the system. This must be a consequence of very few people still using Fortran and thus the interest was not as high as fixing bugs for C/C++ compilers. Mojca -- 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] CMake support for MYS2
On 10 January 2018 at 11:56, Konstantin Tokarev <annu...@yandex.ru> wrote: > 10.01.2018, 11:40, "Mojca Miklavec" <mojca.miklavec.li...@gmail.com>: >> On 8 January 2018 at 17:38, Konstantin Tokarev wrote: >>> 08.01.2018, 14:35, "Mojca Miklavec": >>>> Dear CMake developers, >>>> >>>> I installed msys2 from http://www.msys2.org/ and (after updating etc) >>>> installed cmake via >>>> pacman -S cmake >>> >>> You should install mingw-w64-x86_64-cmake (or i686). >> >> Thank you very much. That package is missing ccmake though > > Please report it as a bug. cmake package should provide ccmake, or > there should be a separate package if ncurses dependency is undesirable > in the main package. I can create a bug report, but I would like to clarify with CMake developers first before I know what exactly to report in the first place. I'm pretty sure that this is a side-effect of CMake's own build figuring out that it's being built on and for Windows, so it probably skips building ccmake and builds cmake-gui.exe instead. This all makes perfect sense for distributing the standalone executable on Windows, but it's less suitable in the context of MSYS2. >>, so I can >> only run cmake directly and even then it strangely(?) defaults to >> Visual Studio when I would expect it to go for Unix Makefiles. > > This is behavior of vanilla cmake, so it's reasonable that it is not altered. I assume it belongs "to the same category" as the lack of ccmake. I can imagine that it would make sense to offer to ways of building cmake on Windows: the "standalone" mode without ccmake, with cmake-gui and defaulting to Visual Studio. And the "command-line" mode with ccmake and defaulting to "Unix Makefiles". Of course one could build both ccmake and cmake-gui at the same time if desired. We often have this problem with a Mac package manager. Many software builds do "if this is mac, then standard unix tools don't exist, so do something completely different" and they would create the app bundle, but skip the rest of command-line friendliness and completely ignore the fact that those unix tools may exist after all. > You can use msys2 like a generic Windows software repository, not only > for MinGW- or MSYS-based development. I admit that I don't totally understand how exactly it's supposed to work, but further discussion would be too off-topic for this list, I assume. >> (The "ccmake" from /usr/bin/ccmake is not helping in any way either, I >> was hoping it would perhaps use mingw-w64-x86_64-cmake.) >> >> I later noticed that there is /mingw64/bin/cmake-gui.exe, but that one >> doesn't really work either: >> >> $ cmake-gui >> C:/msys/msys64/mingw64/bin/cmake-gui.exe: error while loading shared >> libraries: librhash.dll: cannot open shared object file: No such file >> or directory >> >>> You've installed >>> package that targets MSYS environment, not native Windows. >> >> I still assume that others might run into exactly the same isuse in >> the future. Since it's explicitly suggesting to write to the mailing >> list, the reports might repeat. > > This is a packaging problem, so it should be reported to msys2 > maintainers first. OK. > in the meanwhile, you can edit CMakeCache.txt file directly, gui tools > don't really add much :) Well, I can always use cmake -G "..." -Dwhatever ../source but ccmake is useful to show what configuration options the program is offering. Editing CMakeCache is a feasible workaround, but I would like to have a proper fix at the end. Thanks a lot for all the useful insights. Mojca -- 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] CMake support for MYS2
On 8 January 2018 at 17:38, Konstantin Tokarev wrote: > 08.01.2018, 14:35, "Mojca Miklavec": >> Dear CMake developers, >> >> I installed msys2 from http://www.msys2.org/ and (after updating etc) >> installed cmake via >> pacman -S cmake > > You should install mingw-w64-x86_64-cmake (or i686). Thank you very much. That package is missing ccmake though, so I can only run cmake directly and even then it strangely(?) defaults to Visual Studio when I would expect it to go for Unix Makefiles. (The "ccmake" from /usr/bin/ccmake is not helping in any way either, I was hoping it would perhaps use mingw-w64-x86_64-cmake.) I later noticed that there is /mingw64/bin/cmake-gui.exe, but that one doesn't really work either: $ cmake-gui C:/msys/msys64/mingw64/bin/cmake-gui.exe: error while loading shared libraries: librhash.dll: cannot open shared object file: No such file or directory > You've installed > package that targets MSYS environment, not native Windows. I still assume that others might run into exactly the same isuse in the future. Since it's explicitly suggesting to write to the mailing list, the reports might repeat. (OK, I don't expect so many people to use the strange unix toolchains on windows platforms, but still.) Thank you, Mojca >> as well as some other packages like "make", the gcc compiler etc. >> >> But "ccmake" complains: >> >> System is unknown to cmake, create: >> Platform/MINGW32_NT-6.1 to use this system, please send your config file to >> cm...@www.cmake.org so it can be added to cmake >> >> Your CMakeCache.txt file was copied to CopyOfCMakeCache.txt. Please >> send that file to >> cm...@www.cmake.org. >> >> I believe I should additional set the compiler somehow, but I guess I >> should be able to cope with that part. I just wanted to report the >> failure to identify the platform while fighting with other problems. >> (Meson works correctly out of the box.) >> >> CopyOfCMakeCache is in attachment. >> >> Thank you very much, >> Mojca > > -- > Regards, > Konstantin -- 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
[CMake] CMake support for MYS2
Dear CMake developers, I installed msys2 from http://www.msys2.org/ and (after updating etc) installed cmake via pacman -S cmake as well as some other packages like "make", the gcc compiler etc. But "ccmake" complains: System is unknown to cmake, create: Platform/MINGW32_NT-6.1 to use this system, please send your config file to cm...@www.cmake.org so it can be added to cmake Your CMakeCache.txt file was copied to CopyOfCMakeCache.txt. Please send that file to cm...@www.cmake.org. I believe I should additional set the compiler somehow, but I guess I should be able to cope with that part. I just wanted to report the failure to identify the platform while fighting with other problems. (Meson works correctly out of the box.) CopyOfCMakeCache is in attachment. Thank you very much, Mojca # This is the CMakeCache file. # For build in directory: /c/Users/me/test/test-build # It was generated by CMake: /usr/bin/cmake.exe # You can edit this file to change values found and used by cmake. # If you do not want to change any of the values, simply exit the editor. # If you do want to change a value, simply edit, save, and exit the editor. # The syntax for the file is as follows: # KEY:TYPE=VALUE # KEY is the name of a variable in the cache. # TYPE is a hint to GUIs for the type of VALUE, DO NOT EDIT TYPE!. # VALUE is the current value for the KEY. # EXTERNAL cache entries //Path to a program. CMAKE_AR:FILEPATH=CMAKE_AR-NOTFOUND //Choose the type of build, options are: None(CMAKE_CXX_FLAGS or // CMAKE_C_FLAGS used) Debug Release RelWithDebInfo MinSizeRel. CMAKE_BUILD_TYPE:STRING= //Enable/Disable color output during build. CMAKE_COLOR_MAKEFILE:BOOL=ON //CXX compiler CMAKE_CXX_COMPILER:FILEPATH=CMAKE_CXX_COMPILER-NOTFOUND //Flags used by the compiler during all build types. CMAKE_CXX_FLAGS:STRING= //Flags used by the compiler during debug builds. CMAKE_CXX_FLAGS_DEBUG:STRING= //Flags used by the compiler during release builds for minimum // size. CMAKE_CXX_FLAGS_MINSIZEREL:STRING= //Flags used by the compiler during release builds. CMAKE_CXX_FLAGS_RELEASE:STRING= //Flags used by the compiler during release builds with debug info. CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING= //Flags used by the linker. CMAKE_EXE_LINKER_FLAGS:STRING= //Flags used by the linker during debug builds. CMAKE_EXE_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during release minsize builds. CMAKE_EXE_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during release builds. CMAKE_EXE_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during Release with Debug Info builds. CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO:STRING= //Enable/Disable output of compile commands during generation. CMAKE_EXPORT_COMPILE_COMMANDS:BOOL=OFF //Install path prefix, prepended onto install directories. CMAKE_INSTALL_PREFIX:PATH=/usr/local //Path to a program. CMAKE_LINKER:FILEPATH=CMAKE_LINKER-NOTFOUND //Path to a program. CMAKE_MAKE_PROGRAM:FILEPATH=/usr/bin/make.exe //Flags used by the linker during the creation of modules. CMAKE_MODULE_LINKER_FLAGS:STRING= //Flags used by the linker during debug builds. CMAKE_MODULE_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during release minsize builds. CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during release builds. CMAKE_MODULE_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during Release with Debug Info builds. CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO:STRING= //Path to a program. CMAKE_NM:FILEPATH=CMAKE_NM-NOTFOUND //Path to a program. CMAKE_OBJCOPY:FILEPATH=CMAKE_OBJCOPY-NOTFOUND //Path to a program. CMAKE_OBJDUMP:FILEPATH=CMAKE_OBJDUMP-NOTFOUND //Value Computed by CMake CMAKE_PROJECT_NAME:STATIC=CommonLib //Flags used by the linker during the creation of dll's. CMAKE_SHARED_LINKER_FLAGS:STRING= //Flags used by the linker during debug builds. CMAKE_SHARED_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during release minsize builds. CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during release builds. CMAKE_SHARED_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during Release with Debug Info builds. CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO:STRING= //If set, runtime paths are not added when installing shared libraries, // but are added when building. CMAKE_SKIP_INSTALL_RPATH:BOOL=NO //If set, runtime paths are not added when using shared libraries. CMAKE_SKIP_RPATH:BOOL=NO //Flags used by the linker during the creation of static libraries. CMAKE_STATIC_LINKER_FLAGS:STRING= //Flags used by the linker during debug builds. CMAKE_STATIC_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during release minsize builds. CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during release builds. CMAKE_STATIC_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during Release with Debug Info builds.
Re: [CMake] Preventing search for libraries in random prefixes
On Fri, Jun 27, 2014 at 11:28 AM, Angeliki Chrysochou wrote: Hi Mojca, I don't know if removing these paths would break your build maybe...I'm sorry I couldn't help. It wouldn't break my build, but it seems weird and unnatural to do such extensive patching to CMake's Find modules. Mojca -- 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] Preventing search for libraries in random prefixes
Hi,
In our package manager where it is of crucial importance to link
against the proper library we often end up with hardcoding lots and
lots of options, like:
-DOPENGL_INCLUDE_DIR=${prefix}/include \
-DX11_ICE_INCLUDE_PATH=${prefix}/include \
-DX11_SM_INCLUDE_PATH=${prefix}/include \
-DX11_X11_INCLUDE_PATH=${prefix}/include \
-DX11_Xext_INCLUDE_PATH=${prefix}/include \
-DX11_Xft_INCLUDE_PATH=${prefix}/include \
-DX11_Xpm_INCLUDE_PATH=${prefix}/include \
-DX11_ICE_LIB=${prefix}/lib/libICE.dylib \
-DX11_SM_LIB=${prefix}/lib/libSM.dylib \
-DX11_X11_LIB=${prefix}/lib/libX11.dylib \
-DX11_Xext_LIB=${prefix}/lib/libXext.dylib \
-DX11_Xft_LIB=${prefix}/lib/libXft.dylib \
-DX11_Xpm_LIB=${prefix}/lib/libXpm.dylib \
-DOPENGL_gl_LIBRARY=${prefix}/lib/libGL.dylib \
With autotools that usually boiled down to just:
--with-x=${prefix}
My question: is there any way to tell CMake the following?
Please don't search for any libraries or headers from /sw or /usr/X11
or /opt/local or anything, I really really want you to search for the
libraries in /my/special/prefix and only there.
A while back a user asked for removing /sw from CMake FindFoo
modules because that caused him problems. But I would like to
understand the general policy about this.
See:
https://trac.macports.org/ticket/41817
I like that fact that CMake eventually offers more flexibility, but it
makes it a bit painful to ensure that exactly the right libraries are
used. I'm sure that I'm missing something though, so I would like to
understand how to handle this properly.
Thank you,
Mojca
--
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-developers] Weird build error against libc++ on OS X 10.7 (cutting at 1024 characters)
Dear CMake developers, I tried to compile CMake against libc++ on OS X 10.7. For a weird reason it fails: Built target cmsysTestsC [ 25%] Building C object Source/CursesDialog/form/CMakeFiles/cmForm.dir/frm_scale.c.o [ 25%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/IOStream.cxx.o [ 25%] Building C object Source/CursesDialog/form/CMakeFiles/cmForm.dir/frm_sub.c.o [ 25%] Building C object Source/CursesDialog/form/CMakeFiles/cmForm.dir/frm_user.c.o [ 26%] Building C object Source/CursesDialog/form/CMakeFiles/cmForm.dir/frm_win.c.o [ 26%] Building C object Source/CursesDialog/form/CMakeFiles/cmForm.dir/fty_alnum.c.o [ 26%] Building C object Source/CursesDialog/form/CMakeFiles/cmForm.dir/fty_alpha.c.o [ 27%] Building C object Source/CursesDialog/form/CMakeFiles/cmForm.dir/fty_enum.c.o [ 27%] Building C object Source/CursesDialog/form/CMakeFiles/cmForm.dir/fty_int.c.o [ 27%] [ 27%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/SystemInformation.cxx.o Building C object Source/CursesDialog/form/CMakeFiles/cmForm.dir/fty_ipv4.c.o [ 28%] Building C object Source/CursesDialog/form/CMakeFiles/cmForm.dir/fty_num.c.o [ 28%] Building C object Source/CursesDialog/form/CMakeFiles/cmForm.dir/fty_regex.c.o Linking C static library libcmForm.a ar: C: No such file or directory make[2]: *** [Source/CursesDialog/form/libcmForm.a] Error 1 make[2]: Leaving directory `/path/to/cmake-3.0.0' make[1]: *** [Source/CursesDialog/form/CMakeFiles/cmForm.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs Linking CXX static library libcmsys.a make[2]: Leaving directory `/path/to/cmake-3.0.0' [ 28%] Built target cmsys make[1]: Leaving directory `/path/to/cmake-3.0.0' make: *** [all] Error 2 When I use make again and a single core, it fails with [ 66%] Building CXX object Source/CMakeFiles/CMakeLib.dir/cmNinjaUtilityTargetGenerator.cxx.o cd /path/to/cmake-3.0.0/Source /usr/bin/clang++ -DCMAKE_BUILD_WITH_CMAKE -pipe -Os -arch x86_64 -stdlib=libc++ -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk -mmacosx-version-min=10.7 -I/path/to/cmake-3.0.0/Utilities -I/path/to/cmake-3.0.0/Source -I/opt/libcxxlocal/include -I/path/to/cmake-3.0.0/Utilities/cmcompress -I/path/to/cmake-3.0.0/Source/CTest -I/path/to/cmake-3.0.0/Source/CursesDialog/form-o CMakeFiles/CMakeLib.dir/cmNinjaUtilityTargetGenerator.cxx.o -c /path/to/cmake-3.0.0/Source/cmNinjaUtilityTargetGenerator.cxx Linking CXX static library libCMakeLib.a cd /path/to/cmake-3.0.0/Source /path/to/cmake-3.0.0/Bootstrap.cmk/cmake -P CMakeFiles/CMakeLib.dir/cmake_clean_target.cmake cd /path/to/cmake-3.0.0/Source /path/to/cmake-3.0.0/Bootstrap.cmk/cmake -E cmake_link_script CMakeFiles/CMakeLib.dir/link.txt --verbose=1 /usr/bin/ar cr libCMakeLib.a CMakeFiles/CMakeLib.dir/cmStandardIncludes.cxx.o CMakeFiles/CMakeLib.dir/cmArchiveWrite.cxx.o CMakeFiles/CMakeLib.dir/cmBootstrapCommands1.cxx.o CMakeFiles/CMakeLib.dir/cmBootstrapCommands2.cxx.o CMakeFiles/CMakeLib.dir/cmCacheManager.cxx.o CMakeFiles/CMakeLib.dir/cmCommands.cxx.o CMakeFiles/CMakeLib.dir/cmCommandArgumentLexer.cxx.o CMakeFiles/CMakeLib.dir/cmCommandArgumentParser.cxx.o CMakeFiles/CMakeLib.dir/cmCommandArgumentParserHelper.cxx.o CMakeFiles/CMakeLib.dir/cmComputeComponentGraph.cxx.o CMakeFiles/CMakeLib.dir/cmComputeLinkDepends.cxx.o CMakeFiles/CMakeLib.dir/cmComputeLinkInformation.cxx.o CMakeFiles/CMakeLib.dir/cmComputeTargetDepends.cxx.o CMakeFiles/CMakeLib.dir/cmCryptoHash.cxx.o CMakeFiles/CMakeLib.dir/cmCustomCommand.cxx.o CMakeFiles/CMakeLib.dir/cmCustomCommandGenerator.cxx.o CMakeFiles/CMakeLib.dir/cmDefinitions.cxx.o CMakeFiles/CMakeLib.dir/cmDepends.cxx.o CMakeFiles/CMakeLib.dir/cmDependsC.cxx.o CMakeFiles/CMakeLib.dir/cmDependsFortran.cxx.o CMakeFiles/CMak ar: CMakeFiles/CMak: No such file or directory make[2]: *** [Source/libCMakeLib.a] Error 1 make[1]: *** [Source/CMakeFiles/CMakeLib.dir/all] Error 2 make: *** [all] Error 2 The weird part is that part of the command is simply cut off: CMakeFiles/CMakeLib.dir/cmDependsFortran.cxx.o CMakeFiles/CMakcut I looked into Source/CMakeFiles/CMakeLib.dir/link.txt. The first line in that file contains 5356 characters, but the line gets cut off at exactly 1024 when printed on the screen and fails with ar: CMakeFiles/CMak: No such file or directory For some reason the command /path/to/cmake-3.0.0/Bootstrap.cmk/cmake -E cmake_link_script CMakeFiles/CMakeLib.dir/link.txt --verbose=1 isn't outputting the whole command, but cutting it in the middle instead. If I execute that command from link.txt manually, it works ok and the build continues. It then fails again with cd /path/to/cmake-3.0.0/Source /path/to/cmake-3.0.0/Bootstrap.cmk/cmake -E cmake_link_script CMakeFiles/ccmake.dir/link.txt --verbose=1 /usr/bin/clang++ -pipe -Os -arch x86_64 -stdlib=libc++ -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk -mmacosx-version-min=10.7
[CMake] Why CMake automatically uses -isysroot SDKs on OS X?
Hi, I was struggling with a compilation of a project via CMake. Thu build kept failing for unknown reasons until I realized that CMake would automatically compile with -isysroot /Developer/SDKs/MacOSX10.6.sdk \ -mmacosx-version-min=10.6 (or any other sdk, depending on OS version) unless instructed *NOT* to do so by specifying: -DCMAKE_OSX_SYSROOT=/ -DCMAKE_OSX_DEPLOYMENT_TARGET= I had extra problems due to the fact that software which I was compiling called CMake itself and so the projects that were being included and automatically compiled in the process were failing even if I set those two flags. OK, the fact that these two flags weren't passed to the child build was clearly a bug in that software that needs to fixed, but still. Why is the default behavior of CMake to always add -isysroot unless instructed otherwise? I'm compiling from command-line, using cmake -Dflag1 -Dflag2 ... generating gnu makefiles, using CMake version 3.0.0 and clang as the compiler. The reason why I was struggling was because I had to compile C++11 code on OS X 10.6 and have installed libc++ in /usr/lib, but -isysroot reported a broken C++ compiler when that library was absent from the SDK. While that might be a strange reason, there might be other valid cases when one really expects the default behaviour when not passing any flags. Thank you, Mojca -- 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] Proper behaviour and use of CMAKE_INSTALL_* variables
Dear list members, I often like or need to install two versions of the same software. Ideally the software should put its files by default to $prefix/include/$NAME/*.h $prefix/lib/$NAME/*.dylib ... ($prefix = $CMAKE_INSTALL_PREFIX) and in order to be able to install multiple versions side-by-side I would like to be able to specify something like -DCMAKE_INSTALL_INCLUDEDIR=include/$NAME/$VERSION -DCMAKE_INSTALL_LIBDIR=lib/$NAME/$VERSION to end up with $prefix/include/$NAME/$VERSION/*.h $prefix/lib/$NAME/$VERSION/*.dylib instead of default paths. The problem is that in this case either of the two options must be true: a) Software sets CMAKE_INSTALL_INCLUDEDIR to include/$NAME rather than to include by default which violates the convention from http://www.cmake.org/cmake/help/v2.8.12/cmake.html#module:GNUInstallDirs, but leads to the desired behaviour. b) Software sets CMAKE_INSTALL_INCLUDEDIR to include by default and automatically adds $NAME to an internal variable when installing the files. The drawback of this approach is that -DCMAKE_INSTALL_INCLUDEDIR=include/$NAME/$VERSION results in files being installed to $prefix/include/$NAME/$VERSION/$NAME/*.h and there is absolutely no way to change that. What approach would you suggest to achieve the desired behaviour without violating the conventions? Thank you very much, Mojca -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Proper behaviour and use of CMAKE_INSTALL_* variables
On Mon, Dec 9, 2013 at 4:52 PM, Andreas Pakulat wrote: Hi, On Mon, Dec 9, 2013 at 3:50 PM, Mojca Miklavec wrote: Dear list members, I often like or need to install two versions of the same software. Ideally the software should put its files by default to $prefix/include/$NAME/*.h $prefix/lib/$NAME/*.dylib ... ($prefix = $CMAKE_INSTALL_PREFIX) and in order to be able to install multiple versions side-by-side I would like to be able to specify something like -DCMAKE_INSTALL_INCLUDEDIR=include/$NAME/$VERSION -DCMAKE_INSTALL_LIBDIR=lib/$NAME/$VERSION to end up with $prefix/include/$NAME/$VERSION/*.h $prefix/lib/$NAME/$VERSION/*.dylib instead of default paths. Do you have any reasons that speak against using separate prefixes for each version of that software? First, both versions of the software *have to* to be installed under $prefix (in my case that is usually /opt/local) because that is the location where all the packages installed by a specific package manager (MacPorts) need to end up. What I could do is to install the two versions under CMAKE_INSTALL_PREFIX=$prefix/Library/Frameworks/$NAME.framework/Versions/$VERSION/ even if the software doesn't really satisfy the layout of a framework, but that layout doesn't really simplify that much other than no need to specify 5 separate variables to change include, lib, man, doc, ... In particular since such a setup will make your life harder when you want to use the installed software in some cmake-based project. That's not a really good argument. Life is already hard. For FindX11 I need to manually specify about 20 different variables to be able to get rid of searching in /usr/X11R6 (Mac OS X) for example and use the libraries from /opt/local instead. For almost any given library I usually need to specify 2-5 variables (one for includes and several for each single dylib) and a lot of FindWhatever.cmake are simply too stupid to allow easy configuration. The pkg-config approach works a whole lot better in a lot of cases. I would really like to avoid searching in some prefixes (for example I would like to avoid searching for libraries in /usr/local and only search in /opt/local), but I don't know any elegant way to do so. And in case of some specific software I have in mind, the software itself provides its own CMake configuration file, so all dependent packages/software need to do is to find that configuration file, nothing else. In that case you'd have to manually specify include-dir and lib-dir when configuring the project since many find-modules simply expect a 'standard' unix-like layout below the prefix under which they should search for a given software. So they don't look into include/version or lib/version so you'd need to specify that manually. Compared with the ease of just specifying CMAKE_PREFIX_PATH to the installation directory for the version you want thats a lot more effort each time you setup a build directory. I'm still interested in the answer to my original question and would like to avoid discussion about why not specifying a different $prefix. There are surely many pros and contras to each approach and it makes no sense to get off-topic with a different discussion. (I could surely write an essay about pros of my approach, but that wouldn't help me answer my question. I can open a new thread about that if needed, but let's stick to the original question here.) Mojca -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] MSVC++ Express 2010 and msvcp100.dll/msvcr100.dll not found
On Fri, Sep 27, 2013 at 4:08 PM, David Cole wrote: The Express editions of Visual Studio do not contain the redistributable libraries. You may build software and use it on your own computer with the Express editions, but you are not able to create redistributable software with it that works on other machines unless you link everything you need statically. To redistribute the software you build with VS, you need to buy a license to one of the paid editions. Thank you for the explanation. But wouldn't it then make more sense to throw a warning like Warning: you are using a free version of Visual Studio which doesn't contain distributable libraries. You will only be able to run the binaries on your own computer. If you want to distribute the binaries you need to install the full version. rather than the following cryptic message? system runtime library file does not exist: 'MSVC10_REDIST_DIR-NOTFOUND/x86/Microsoft.VC100.CRT/msvcr100.dll' Call Stack (most recent call first): cmake/modules/RootCPack.cmake:9 (include) CMakeLists.txt:107 (include) When I first saw the message I thought it was an error and that I wouldn't be able to compile the software at all. My second feature request will probably be to use a different colour for warnings than for errors in cmake-gui ;) Thank you, Mojca -- 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://www.cmake.org/mailman/listinfo/cmake
[CMake] MSVC++ Express 2010 and msvcp100.dll/msvcr100.dll not found
Hello, I installed Visual C++ Express 2010 on XP and I'm trying to compile my first CMake-based project. I installed CMake 2.8.12-rc3. The first confusion was that I wasn't sure which generator to choose with cmake-gui. there is a mention of versions 2005 and 2008, but other Microsoft's products are numbered without a year, only version 10, 11, 12, ... and it took me a while to guess which number is which. Only later I found a very well hidden http://en.wikipedia.org/wiki/Microsoft_Visual_Studio#Version_history. I would like to request making those versions in cmake-gui more explicit (adding the release year in description to be able to find the right target more easily). I have selected version 10 as the target. Everything runs fine except for this at the end: CMake Warning at C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/InstallRequiredSystemLibraries.cmake:351 (message): system runtime library file does not exist: 'MSVC10_REDIST_DIR-NOTFOUND/x86/Microsoft.VC100.CRT/msvcp100.dll' Call Stack (most recent call first): cmake/modules/RootCPack.cmake:9 (include) CMakeLists.txt:107 (include) CMake Warning at C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/InstallRequiredSystemLibraries.cmake:351 (message): system runtime library file does not exist: 'MSVC10_REDIST_DIR-NOTFOUND/x86/Microsoft.VC100.CRT/msvcr100.dll' Call Stack (most recent call first): cmake/modules/RootCPack.cmake:9 (include) CMakeLists.txt:107 (include) The second file is at C:\Program Files\Microsoft\Microsoft Visual Studio 10.0\Common7\Packages\Debugger\X64\msvcr100.dll and I don't find the first one. What is the MSVC10_REDIST_DIR-NOTFOUND? Is this something I should worry about? Thank you, Mojca -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Unsupported -arch x86_64 mysteriously ends up in Fortran_FLAGS
On Wed, Jan 23, 2013 at 5:29 PM, Brad King wrote: On 01/22/2013 02:11 PM, Mojca Miklavec wrote: I realised that an unsupported compiler flag -arch x86_64 mysteriously sneaks into Fortran_FLAGS when -DCMAKE_OSX_ARCHITECTURES=x86_64 The -arch flag is hard-coded here: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmLocalGenerator.cxx;hb=v2.8.10.2#l1826 It was added to CMake way back when universal binary support was first added to OS X under the assumption that all compilers that would be used in combination with CMAKE_OSX_ARCHITECTURES would support the flag. Obviously the assumption is wrong. True. Not even the original gcc compilers (without Apple's modifications) support the -arch flag. MacPorts ship the original gcc compilers and actually use them for a couple of ports. I'm not 100% sure, but some of the reasons include faster and more efficient computations in physics simulations (apparently using the latest gcc 4.8 matters) or support for Fortran. So testing for Mac OS X and GCC doesn't yet guarantee the existence of that flag. The hard-coded flag needs to be replaced with a lookup of a new per-language platform information variable, perhaps called CMAKE_LANG_OSX_ARCHITECTURE_FLAG Thanks a lot for the answer. Since you know the internals much better than I do: do I have to file a bug report myself? Thanks again, Mojca -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Unsupported -arch x86_64 mysteriously ends up in Fortran_FLAGS
Dear CMake developers,
I'm a newbie to CMake (I've never written any project myself), but
while trying to install a physics package Root from the master of
https://github.com/bbannier/ROOT (https://root.cern.ch/svn/root/trunk)
I realised that an unsupported compiler flag -arch x86_64
mysteriously sneaks into Fortran_FLAGS when
-DCMAKE_OSX_ARCHITECTURES=x86_64
is passed to cmake. That flag CMAKE_OSX_ARCHITECTURES is added
automatically to all projects in MacPorts (third-party package manager
for Mac OS X) even when cross-compiling or compilation of fat binaries
(like i386+x86_64) is not needed.
The g95 compiler ignores -arch ... flag, but GCC's gfortran 4.x
throws an error and breaks compilation. I could probably try to
prevent DCMAKE_OSX_ARCHITECTURES from being passed to cmake (via some
tricks in MacPorts or by modifying MacPorts sources), but I still
believe that passing -arch x86_64 to Fortran_FLAGS is a bug in
CMake. I tried to figure out when those flags are set, but I don't
know enough about CMake. I've seen several places where compiler flags
are simply copied from C to Fortran, for example here:
# Create a set of shared library variable specific to Fortran
# For 90% of the systems, these are the same flags as the C versions
# so if these are not set just copy the flags from the c version
if(NOT DEFINED CMAKE_SHARED_LIBRARY_CREATE_Fortran_FLAGS)
set(CMAKE_SHARED_LIBRARY_CREATE_Fortran_FLAGS
${CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS})
endif()
but I don't have enough knowledge to be able to track the problem down
to a single spot. There is a slight chance that the problematic flag
is introduced by the project, but there are other projects in MacPorts
suffering from the same symptoms.
The command that I used to compile Root:
cmake \
-DCMAKE_Fortran_COMPILER=/opt/local/bin/gfortran-mp-4.5 \
-DCMAKE_C_COMPILER=/usr/bin/clang \
-DCMAKE_CXX_COMPILER=/usr/bin/clang++ \
-DCMAKE_INSTALL_PREFIX=/path/to/install \
-DCMAKE_OSX_ARCHITECTURES=x86_64 ../root_trunk
In case that anyone would want to try it on the particular project,
the generated file
misc/minicern/CMakeFiles/minicern.dir/flags.make
ends up containing the following variables (among others):
C_FLAGS = -m64 -pipe -W -Wall -fsigned-char -fno-common -O2 -g
-arch x86_64 -fPIC -Ipath/to/some/include/dirs
Fortran_FLAGS = -m64 -std=legacy -arch x86_64 -fPIC
-Ipath/to/some/include/dirs
(Another problem is that -std=legacy is not recognised by g95 and
throws another error, but that one is a bug in the project.) I also
didn't know how to disable Fortran compiler altogether, but that's a
completely different issue.
I'm using 64-bit Mac OS X 10.7.4, cmake version 2.8.10.
I would be very grateful for any insight about how to get rid of that
-arch x86_64 flag. Thanks and best regards,
Mojca
Related tickets:
- https://trac.macports.org/ticket/37732 (about the -arch flag in Fortran)
- https://trac.macports.org/ticket/37688 ([also] about development of
a package for Root using CMake)
- https://savannah.cern.ch/bugs/index.php?99944 (not strictly related though)
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
