Re: [cmake-developers] automatically download library
On Oct 8, 2015, at 10:06 AM, Marsel Galimullin wrote: > The idea is that CMake has possibility to contact with package managers for > download necessary libraries. > If “find_package” can’t find a library, it need to call apt-get install. > Example: >auto_downland(apt-get) >find_package (Boost COMPONENTS system thread REQUIRED) I understand the idea, and I'm telling you that if you need this for your own personal project -- one that will never be included in a package management system -- then do whatever you like. But if you are proposing this as something that should be included in cmake, and you are suggesting that it could be used by any project that wants to -- even in projects that might someday be included in a package management system -- then I can tell you that this would not be welcomed by the people who maintain those package management systems. I am such a person. If I were tasked with the request to add to my package management system a project that wanted to control the installation of its own dependencies, or that in some other way tried to be in charge of downloading its dependencies, I would either have to rip all that code out, or more likely I would reject the request to add that project as being too labor-intensive. It is the package management system's job to download and install dependencies, not the job of the project's build system. -- 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-developers
Re: [cmake-developers] automatically download library
On Oct 6, 2015, at 7:22 AM, Марсель Галимуллин wrote: > I'm student of the University LETI and as a masrer's thesis I want to develop > an extension to CMake. It is expected that this extension will automatically > download missing library if instruction such as «find_package (Boost > COMPONENTS system thread REQUIRED)» can not find the package. Could you give > me some advices where to begin and which the best direction to design, > develop and whether to do it? If you need that for some special purpose, go for it, but it's probably not a behavior most users would expect, and it's definitely a behavior that would have to be disabled in any software installed by a package management system. (The package management system would want to be in control of what gets downloaded.) -- 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-developers
Re: [cmake-developers] cmake fails to identify C and CXX compiler when building universal
On Sep 29, 2015, at 1:54 AM, Nils Gladitz wrote: > Is it possible that beyond setting CMAKE_OSX_ARCHITECTURES the project also > tries to manually add -arch flags to CFLAGS/CXXFLAGS? > > The test binary produced for compiler identification with just > CMAKE_OSX_ARCHITECTURES set is not a fat binary for me and identification is > successful (CMake 3.3.2). > > Manually adding "-arch x86_64 -arch i386" to the compiler flags breaks this > since now the test binary itself is also fat. You are correct: in addition to giving cmake the -DCMAKE_OSX_ARCHITECTURES="x86_64;i386" argument, MacPorts includes "-arch x86_64 -arch i386" in the CFLAGS, CXXFLAGS, and LDFLAGS environment variables. I am not certain, but I think the only reason why we are doing this for cmake-using ports is that we do this for all ports, and no code was ever added to override this for cmake-using ports. Perhaps this didn't cause problems before, or we never noticed it caused problems before. I will work adding code to MacPorts to remove these flags for cmake-using ports. Thanks for the suggestion. -- 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-developers
[cmake-developers] cmake fails to identify C and CXX compiler when building universal
Hello, I am a developer with the MacPorts package management system, and I want to report to you a bug in cmake 3.3.2 that affects OS X. I was going to file a bug report in your issue tracker, but the bright yellow box at the top of the "report issue" page made it sound like I should send my report here instead. The problem is that cmake cannot identify the compiler, when compiling any project (that uses cmake) universally (i.e. for more than one architecture, e.g. for both x86_64 and i386): -- cmake version 3.3.2 -- The C compiler identification is unknown -- The CXX compiler identification is unknown This could cause programs that rely on identifying the compiler to either build incorrectly or even (e.g. in the case of x265) to fail to build at all. For cross-referencing purposes, this problem was previously reported to the MacPorts project here: https://trac.macports.org/ticket/48331 The problem does not occur when compiling non-universally (i.e. for only a single architecture, e.g. for only x86_64): -- The C compiler identification is AppleClang 7.0.0.772 -- The CXX compiler identification is AppleClang 7.0.0.772 I found that in CMakeDetermineCompilerId.cmake, cmake compiles a test program (CMAKE_DETERMINE_COMPILER_ID_BUILD) which defines certain strings that describe the compiler, and then examines the strings in the compiled a.out file (CMAKE_DETERMINE_COMPILER_ID_CHECK). If the file contains more than one "INFO:compiler[...]" string, cmake assumes something went wrong and sets COMPILER_ID_TWICE to 1 which causes the compiler id to be forgotten. The problem is that when building universal, the a.out file produced by the test will contain multiple copies of the strings -- once for each architecture. What the compiler does for you when you use multiple -arch flags is to compile the file separately, once for each architecture, then glue the separate files together into a single file (using the lipo program), so naturally such a file will contain multiple copies of any strings. This is not a bug; this is how universal binaries work. The bug is that cmake considers this valid condition to be erroneous. Here is an example of the duplicated strings: $ lipo -info build/CMakeFiles/3.3.2/CompilerIdC/a.out Architectures in the fat file: work/build/CMakeFiles/3.3.2/CompilerIdC/a.out are: x86_64 i386 $ strings -arch all build/CMakeFiles/3.3.2/CompilerIdC/a.out INFO:compiler[AppleClang] INFO:platform[Darwin] INFO:arch[] INFO:compiler_version[0007...0772] INFO:compiler[AppleClang] INFO:platform[Darwin] INFO:arch[] INFO:compiler_version[0007...0772] (I know cmake uses its internal FILE(STRINGS) command, not the strings program, but I presume they are similar.) I was able to get cmake to correctly identify the compilers even when building universal by simply removing the COMPILER_ID_TWICE stuff from CMakeDetermineCompilerId.cmake, but perhaps you want something more elegant that verifies that if there are multiple definitions of a particular info line, all the definitions are the same. -- 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-developers