Re: [cmake-developers] automatically download library
On 08-Oct-15 18:06, 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) re:{possibility to contact with package managers} *if* you have a suitable package manager. And even if you have one result may differs for different platforms, e.g.: * OSX, brew install boost => 1.58 * Ubuntu, apt-get install boost-dev => 1.54 Note that 'find_package(Boost)' can find any user-installed libraries or non-host packages for cross-compile, like building Android on Linux, or iOS on OSX (both issues can be solved by using ExternalProject + superbuild). If you and your users are okay with that then it's should be not so hard to implement this CMake module. On 06-Oct-15 15:22, Marsel Galimullin wrote: Hello! I'm student of the University LETI and as a masrer'sthesis I want to developan extension to CMake. It is expected that this extension will automatically download missinglibrary ifinstruction 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, developand whether to do it? So with all this peculiarities I've described above this will be not such an easy task as you might expect. You can start one from scratch for education or fun (or both) but if you want to do some really helpful stuff my advice to you is to feed "cmake package manager" request to your web search engine and investigate existing solutions. On 08-Oct-15 18:41, Ryan Schmidt wrote: 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. re:{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} this can be solved easily by adding option which is set to OFF by default: option(USE_SUPERTOOL "Download host packages automatically" OFF) function(auto_download ...) if(NOT USE_SUPERTOOL) # do nothing return() endif() # do install endfunction() auto_download(...) # by default do nothing find_package(Boost COMPONENT system thread REQUIED) # find the packages you are expecting On 08-Oct-15 18:23, Brad King wrote: On 10/08/2015 11: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) This does not provide enough information to know what package to install. This problem is not in scope for a build system. Another tool should be used to install dependencies ahead of time before running CMake. The source tree could come with some kind of dependency spec file for such a tool to use but this would be independent of the build system. -Brad re:{The source tree could come with some kind of dependency spec file for such a tool to use but this would be independent of the build system} As the one who is using such approach in my product I disagree with that completely :) CMake code and dependencies are in fact coupled strongly. For example: option(USE_GUI "Use some GUI for this project" OFF) if(USE_GUI) if(WIN32) option(USE_QT "Use Qt GUI" ON) else() option(USE_WXWIDGETS "Use WxWidgets GUI" ON) endif() # check at least one and not both if(USE_QT) f
Re: [cmake-developers] [CMake 0015769]: OS X: Filesystem timestamp checks use only 1s resolution
On 10-Oct-15 01:00, Ruslan Baratov via cmake-developers wrote: On 08-Oct-15 21:03, Mantis Bug Tracker wrote: The following issue has been ASSIGNED. == https://cmake.org/Bug/view.php?id=15769 == Reported By:Ruslan Baratov Assigned To:Brad King == Project:CMake Issue ID: 15769 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: resolved Target Version: CMake 3.5 Resolution: fixed Fixed in Version: CMake 3.5 == Date Submitted: 2015-10-05 10:37 EDT Last Modified: 2015-10-08 14:03 EDT == Summary:OS X: Filesystem timestamp checks use only 1s resolution Description: `cmake --build` command doesn't trigger reconfiguration of the project on OS X when CMakeLists.txt changed. Example: add_executable(foo foo.cpp) # file foo.cpp exists cmake -H. -B_builds cmake --build _builds # OK change: add_executable(foo foo.cpp boo.cpp) # file boo.cpp not exists cmake --build _builds # expected error, but no error reported Ready-to-run example can be found: https://github.com/forexample/cmake-osx-no-reconfigure-bug Log from OS X machine: *https://travis-ci.org/forexample/cmake-osx-no-reconfigure-bug/builds/83701171 Log for similar test on Linux machine: *https://travis-ci.org/forexample/cmake-osx-no-reconfigure-bug/builds/83702953 CMake on Linux machine run reconfigure command and report an error: cmake -H. -B_builds --check-build-system CMakeFiles/Makefile.cmake 0 -- Configuring done CMake Error at CMakeLists.txt:4 (add_executable): Cannot find source file: boo.cpp same error expected on OS X machine == -- (0039511) Brad King (manager) - 2015-10-05 14:45 https://cmake.org/Bug/view.php?id=15769#c39511 -- I can reproduce this when running 'make' directly without 'cmake --build': -cmake --build _builds +(cd _builds; make) The problem is that the filesystem and/or make tool seem to have 1s timestamp resolution. If I change the script to do "sleep 1" before the last "cp CMakeBad.txt CMakeLists.txt" then it works. -- (0039512) Brad King (manager) - 2015-10-05 14:52 https://cmake.org/Bug/view.php?id=15769#c39512 -- The issue may be where CMake decides whether it needs to re-run: https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmFileTimeComparison.cxx;hb=v3.3.2#l147 The STAT_HAS_ST_MTIM code path may not be taken on this platform. -- (0039513) Brad King (manager) - 2015-10-05 14:54 https://cmake.org/Bug/view.php?id=15769#c39513 -- Indeed, on OS X "struct stat" has: struct timespec st_mtimespec; instead of struct timespec st_mtim; -- (0039518) Brad King (manager) - 2015-10-06 13:27 https://cmake.org/Bug/view.php?id=15769#c39518 -- For reference, I've started a fix for this on the KWSys side here: http://review.source.kitware.com/20258/ -- (0039519) Brad King (manager) - 2015-10-06 14:04 https://cmake.org/Bug/view.php?id=15769#c39519 -- It looks like the underlying HFS filesystem only has 1s resolution: https://en.wikipedia.org/wiki/HFS_Plus This may not be possible to fix without a "sleep 1" in the test script. -- (0039548) Brad King (manager) - 2015-10-08 14:01 https://cmake.org/Bug/view.php?id=15769#c39548 -- After the KWSys side learned to use st_mtimespec I've updated CMake too: cmFileTimeComparison: Port to OS X nanosecond times https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8d27b407 -- (0039549) Brad King (manager) - 2015-10-08 14:03 https://cmake.org/Bug/view.php?id=157
Re: [cmake-developers] [CMake 0015769]: OS X: Filesystem timestamp checks use only 1s resolution
On 08-Oct-15 21:03, Mantis Bug Tracker wrote: The following issue has been ASSIGNED. == https://cmake.org/Bug/view.php?id=15769 == Reported By:Ruslan Baratov Assigned To:Brad King == Project:CMake Issue ID: 15769 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: resolved Target Version: CMake 3.5 Resolution: fixed Fixed in Version: CMake 3.5 == Date Submitted: 2015-10-05 10:37 EDT Last Modified: 2015-10-08 14:03 EDT == Summary:OS X: Filesystem timestamp checks use only 1s resolution Description: `cmake --build` command doesn't trigger reconfiguration of the project on OS X when CMakeLists.txt changed. Example: add_executable(foo foo.cpp) # file foo.cpp exists cmake -H. -B_builds cmake --build _builds # OK change: add_executable(foo foo.cpp boo.cpp) # file boo.cpp not exists cmake --build _builds # expected error, but no error reported Ready-to-run example can be found: https://github.com/forexample/cmake-osx-no-reconfigure-bug Log from OS X machine: * https://travis-ci.org/forexample/cmake-osx-no-reconfigure-bug/builds/83701171 Log for similar test on Linux machine: * https://travis-ci.org/forexample/cmake-osx-no-reconfigure-bug/builds/83702953 CMake on Linux machine run reconfigure command and report an error: cmake -H. -B_builds --check-build-system CMakeFiles/Makefile.cmake 0 -- Configuring done CMake Error at CMakeLists.txt:4 (add_executable): Cannot find source file: boo.cpp same error expected on OS X machine == -- (0039511) Brad King (manager) - 2015-10-05 14:45 https://cmake.org/Bug/view.php?id=15769#c39511 -- I can reproduce this when running 'make' directly without 'cmake --build': -cmake --build _builds +(cd _builds; make) The problem is that the filesystem and/or make tool seem to have 1s timestamp resolution. If I change the script to do "sleep 1" before the last "cp CMakeBad.txt CMakeLists.txt" then it works. -- (0039512) Brad King (manager) - 2015-10-05 14:52 https://cmake.org/Bug/view.php?id=15769#c39512 -- The issue may be where CMake decides whether it needs to re-run: https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmFileTimeComparison.cxx;hb=v3.3.2#l147 The STAT_HAS_ST_MTIM code path may not be taken on this platform. -- (0039513) Brad King (manager) - 2015-10-05 14:54 https://cmake.org/Bug/view.php?id=15769#c39513 -- Indeed, on OS X "struct stat" has: struct timespec st_mtimespec; instead of struct timespec st_mtim; -- (0039518) Brad King (manager) - 2015-10-06 13:27 https://cmake.org/Bug/view.php?id=15769#c39518 -- For reference, I've started a fix for this on the KWSys side here: http://review.source.kitware.com/20258/ -- (0039519) Brad King (manager) - 2015-10-06 14:04 https://cmake.org/Bug/view.php?id=15769#c39519 -- It looks like the underlying HFS filesystem only has 1s resolution: https://en.wikipedia.org/wiki/HFS_Plus This may not be possible to fix without a "sleep 1" in the test script. -- (0039548) Brad King (manager) - 2015-10-08 14:01 https://cmake.org/Bug/view.php?id=15769#c39548 -- After the KWSys side learned to use st_mtimespec I've updated CMake too: cmFileTimeComparison: Port to OS X nanosecond times https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8d27b407 -- (0039549) Brad King (manager) - 2015-10-08 14:03 https://cmake.org/Bug/view.php?id=15769#c39549 -- Marking
Re: [cmake-developers] automatically download library
Thanks for your comments. 08.10.2015 18:41, Ryan Schmidt пишет: 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. -- Kind regards, Marsel Galimullin. -- 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] Xcode build settings and BullseyeCoverage
Hello, Im trying to configure and build a project with the Xcode generator and the bullseye coverage tool. Without the bullseye coverage tool it works fine but if I want to use it I had to do the following workaround: http://www.bullseye.com/help/tool-xcode.html In short words, the clang and clang++ ExecPath would be changed from clang => $(PLATFORM_DEVELOPER_BIN_DIR)/clang and clang++ => $(PLATFORM_DEVELOPER_BIN_DIR)/clang++ Before I made the changes, CMake finds clang/clang++ under /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolch ain/usr/bin/clang, with the changes CMake tries to find clang/clang++ under /Applications/Xcode.app/Contents/Developer/usr/bin/clang which doesnt exist. And I got the following error: -- The C compiler identification is unknown -- The CXX compiler identification is unknown CMake Error at CMakeLists.txt:3 (project): No CMAKE_C_COMPILER could be found. CMake Error at CMakeLists.txt:3 (project): No CMAKE_CXX_COMPILER could be found. -- Configuring incomplete, errors occurred! However, without the changes I could build the project with cmake build . -- -showBuildSettings which gives me the following information . . . PLATFORM_DEVELOPER_APPLICATIONS_DIR = /Applications/Xcode.app/Contents/Developer/Applications PLATFORM_DEVELOPER_BIN_DIR = /Applications/Xcode.app/Contents/Developer/usr/bin PLATFORM_DEVELOPER_LIBRARY_DIR = /Applications/Xcode.app/Contents/Developer/Library PLATFORM_DEVELOPER_SDK_DIR = /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Develop er/SDKs PLATFORM_DEVELOPER_TOOLS_DIR = /Applications/Xcode.app/Contents/Developer/Tools PLATFORM_DEVELOPER_USR_DIR = /Applications/Xcode.app/Contents/Developer/usr PLATFORM_DIR = /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform . . . Why doesnt find CMake Xcode with the modified path? Is there also a way to set generator specific things during configure time? At the moment it is only possible with the build command: cmake -build . -- PLATFORM_DEVELOPER_BIN_DIR=PointToSomething which sets the build settings for Xcode Thanks in advance Best Regards Roman -- 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] ITK NIfTI broken Oct 6
The ITK dashboard builds on bubbles, murron, and k450e all started failing at the configure step on October 6. These builds all use the development version of CMake. There were no remarkable changes in ITK that night, however there were some interesting updates to CMake. The errors are in the third party library NIfTI and look like this : CMake Error at Modules/ThirdParty/NIFTI/src/nifti/znzlib/CMakeLists.txt:18 (install): install TARGETS given no LIBRARY DESTINATION for shared library target "znz". CMake Error at Modules/ThirdParty/NIFTI/src/nifti/znzlib/CMakeLists.txt:28 (install): install FILES given no DESTINATION! signature.asc Description: OpenPGP digital signature -- 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] CXX_STANDARD and linking
No problem for me to keep broken behavior of SolarisStudio. Let me know when C++ Standard support including linking part is implemented, I can help you to validate it on Solaris SPARC. Thanks. Marc On 08/10/15 19:24, "cmake-developers on behalf of Brad King" wrote: >On 10/08/2015 11:38 AM, Brad King wrote: >> On 10/07/2015 03:22 PM, Stephen Kelly wrote: >>> The CMake 3.3 behavior of this is the same as it has always been since >>> introducing compile-features for SolarisStudio. >> >> Well that behavior was broken. We never had a nightly dashboard for it. >> Now I got nightly testing set up and it fails many tests without my changes. > >OTOH I should not have rushed in this change for 3.4. We can just let >it act as 3.3 did and no one will be worse off. Then we can pick this >up in post-3.4 development. Reverted for now: > > Revert topic 'compiler-features-solaris' > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=340d0897 > >I've scheduled this for the 'release' branch for 3.4.0-rc2. > >-Brad > >-- > >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 -- 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