From brad.king at kitware.com Tue Dec 1 09:11:56 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 1 Dec 2015 09:11:56 -0500 Subject: [cmake-developers] Add CXX_STANDARD support for Intel C++ compilers In-Reply-To: References: <564B9E45.6090002@kitware.com> <564CAB28.9020101@kitware.com> <564CDA4F.9070503@kitware.com> <564DED8E.1030907@kitware.com> <565C9683.6060209@kitware.com> Message-ID: <565DAAAC.3010108@kitware.com> On 11/30/2015 02:13 PM, Levi Morrison wrote: > Hmm. Thanks. I applied it yesterday and merged to 'next' for testing: Features: Record standards and features for Intel C++ on UNIX https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=117d49b8 However, it fails the Module.WriteCompilerDetectionHeader test: https://open.cdash.org/testDetails.php?test=396604477&build=4124323 For now I reverted it from 'next' until we address this failure. The WriteCompilerDetectionHeader module and its test need updates to record support for the Intel compiler features. Thanks, -Brad From brad.king at kitware.com Tue Dec 1 09:13:14 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 1 Dec 2015 09:13:14 -0500 Subject: [cmake-developers] [PATCH] Fix building on musl-libc In-Reply-To: References: <565C6DF8.7040405@kitware.com> Message-ID: <565DAAFA.8030205@kitware.com> On 11/30/2015 11:05 PM, Kylie McClain wrote: >> Does work here instead? > > Yes, appears to work just fine. Thanks. Applied accordingly: Include `sys/types.h` header to get `mode_t` https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=16f5d184 -Brad From gjasny at googlemail.com Tue Dec 1 09:22:19 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Tue, 1 Dec 2015 15:22:19 +0100 Subject: [cmake-developers] Please comment on ios-universal topic Message-ID: <565DAD1B.60301@googlemail.com> Hello, During the last days I worked on the iOS Universal Install topic which now would benefit from a review. Especially the core changes could need a third pair of eyes: https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=8fb23b42cfc2fb7490e8645fff328add9c231713 I will now concentrate on adding more tests during the next days. Thank you, Gregor From brad.king at kitware.com Tue Dec 1 10:28:11 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 1 Dec 2015 10:28:11 -0500 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: <565CA0A7.2090705@gmail.com> References: <565C90E1.70104@kitware.com> <565CA0A7.2090705@gmail.com> Message-ID: <565DBC8B.9070402@kitware.com> On 11/30/2015 02:16 PM, Michael Scott wrote: > Great, I've changed the nullptr references to NULL instead. Thanks. Applied with minor tweaks and merged to 'next' for testing: Merge topic 'cmake-W-options' into next https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cfcc9d52 -Brad From rleigh at codelibre.net Tue Dec 1 10:58:20 2015 From: rleigh at codelibre.net (rleigh at codelibre.net) Date: Tue, 1 Dec 2015 15:58:20 -0000 (GMT) Subject: [cmake-developers] [PATCH] FindBoost: Add imported targets In-Reply-To: <565C8BFF.6030006@kitware.com> References: <04b1182ca36b00d00feeefb7de0e7498.squirrel@g.mail.aa.net.uk> <67B03964-3C58-4949-BC7B-D5E880AA55DE@gmail.com> <5649EA9E.7050300@kitware.com> <18d16f5656fe07593344c5bbc42e3c5f.squirrel@g.mail.aa.net.uk> <565B03BE.3050303@codelibre.net> <565C7A50.6050203@kitware.com> <565C8BFF.6030006@kitware.com> Message-ID: <2fd1d7bbf89718f7d8007e229366b002.squirrel@g.mail.aa.net.uk> > On 11/30/2015 11:54 AM, rleigh at codelibre.net wrote: >> I do worry about the maintenance burden of hardcoding the information in >> the script. > > I do too. We already have to update the script for each Boost release. > This is among the reasons the work is better integrated with upstream > Boost instead. I'd definitely like to see this for future Boost releases, though for historical releases we're a bit stuck. I'll revisit the work I pointed to and see if I can figure out bjam/boost-build and integrate this, since it would effectively give us CMake configuration "for free" off the back of the autolink data, and would also come directly from the compiler so wouldn't require parsing all the headers by hand. >> How should this cater for dependency changes between boost releases? >> How far back in time does this dependency information need to go? > > One would need to fill out tables per version and then detect the > version to populate the info. Just don't provide imported targets > if the version does not have dependency info available. If someone > needs it they can run something to fill out the tables for their > version and submit a patch. I've attached an updated version of the patch which does this. The behaviour is otherwise identical to the earlier patches. It's less awful than I expected--the information for many Boost releases was the same so it could be reduced in size significantly. This also includes a utility script to do the parsing, so it can be potentially used for future Boost releases as well. I've run the script against all versions of Boost supported by the script, and it's verified with the unit test for some of the components. Just FYI, the boost components in 1.59 are as follows: Header Library Mismatched name --------------- ------------------- --------------- archive serialization * archive wserialization * atomic atomic chrono chrono container container context context coroutine2 coroutine * coroutine coroutine date_time date_time endian endian filesystem filesystem iostreams iostreams locale locale log date_time (*) log log log log_setup math math_c99 * math math_c99f * math math_c99l * math math_tr1 * math math_tr1f * math math_tr1l * mpi mpi mpi mpi_python * program_options program_options python python random random regex regex serialization serialization signals signals system system test prg_exec_monitor * test test_exec_monitor * test unit_test_framework * thread thread timer timer wave wave The dependency parsing handles the case where the component library name matches the include directory name. For most cases, this is correct, but there are cases marked * where it isn't. These cases require the user to request the appropriate component name by hand with find_package (since the include directory name isn't a valid component name). For most cases we can't make the assumption since e.g. if you use we have no idea which serialisation library to use; and if you use we don't know which of the math_* libraries you /might/ use. We have to leave that up to the user. Likewise for . For these libraries we also need to special-case the dependency info since we can't easily get it via the headers; currently only mpi_python needed handling in this way; the others have no dependencies. The above isn't really a problem, it's just something to be aware of which limits just how user-friendly we can make things. The granularity of the FindBoost component selection means the user will need to know which libraries they need when they use certain headers; but this was already the case for the variables, and is no different for the imported targets. Regards, Roger -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-FindBoost-Add-imported-targets.patch Type: text/x-diff Size: 27799 bytes Desc: not available URL: From brad.king at kitware.com Tue Dec 1 11:19:00 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 1 Dec 2015 11:19:00 -0500 Subject: [cmake-developers] [PATCH] FindBoost: Add imported targets In-Reply-To: <2fd1d7bbf89718f7d8007e229366b002.squirrel@g.mail.aa.net.uk> References: <04b1182ca36b00d00feeefb7de0e7498.squirrel@g.mail.aa.net.uk> <67B03964-3C58-4949-BC7B-D5E880AA55DE@gmail.com> <5649EA9E.7050300@kitware.com> <18d16f5656fe07593344c5bbc42e3c5f.squirrel@g.mail.aa.net.uk> <565B03BE.3050303@codelibre.net> <565C7A50.6050203@kitware.com> <565C8BFF.6030006@kitware.com> <2fd1d7bbf89718f7d8007e229366b002.squirrel@g.mail.aa.net.uk> Message-ID: <565DC874.4000903@kitware.com> On 12/01/2015 10:58 AM, rleigh at codelibre.net wrote: > I'd definitely like to see this for future Boost releases, though for > historical releases we're a bit stuck. I'll revisit the work I pointed to > and see if I can figure out bjam/boost-build and integrate this, since it > would effectively give us CMake configuration "for free" off the back of > the autolink data, and would also come directly from the compiler so > wouldn't require parsing all the headers by hand. Good. Once Boost provides that then our FindBoost script can switch to looking for it when the version number is high enough. > I've attached an updated version of the patch which does this. The > behaviour is otherwise identical to the earlier patches. It's less awful > than I expected--the information for many Boost releases was the same so > it could be reduced in size significantly. This also includes a utility > script to do the parsing, so it can be potentially used for future Boost > releases as well. I've run the script against all versions of Boost > supported by the script, and it's verified with the unit test for some of > the components. [snip] > The dependency parsing handles the case where the component library name > matches the include directory name. For most cases, this is correct, but > there are cases marked * where it isn't. These cases require the user to > request the appropriate component name by hand with find_package (since > the include directory name isn't a valid component name). For most cases > we can't make the assumption since e.g. if you use we have > no idea which serialisation library to use; and if you use we > don't know which of the math_* libraries you /might/ use. We have to > leave that up to the user. Likewise for . For these > libraries we also need to special-case the dependency info since we can't > easily get it via the headers; currently only mpi_python needed handling > in this way; the others have no dependencies. Great. Please split this up into a few commits, perhaps: - Add parsing script, perhaps `Utilities/Scripts/BoostScanDeps.cmake`. I see it documents in the comments the need for special cases already. Please also add a comment next to each special case to explain it. - Run script to populate the table in FindBoost.cmake. Document in the commit message the range of versions included. - Add imported targets using the now-available tables. Thanks, -Brad From morrison.levi at gmail.com Tue Dec 1 12:47:12 2015 From: morrison.levi at gmail.com (Levi Morrison) Date: Tue, 1 Dec 2015 10:47:12 -0700 Subject: [cmake-developers] Add CXX_STANDARD support for Intel C++ compilers In-Reply-To: <565DAAAC.3010108@kitware.com> References: <564B9E45.6090002@kitware.com> <564CAB28.9020101@kitware.com> <564CDA4F.9070503@kitware.com> <564DED8E.1030907@kitware.com> <565C9683.6060209@kitware.com> <565DAAAC.3010108@kitware.com> Message-ID: On Tue, Dec 1, 2015 at 7:11 AM, Brad King wrote: > On 11/30/2015 02:13 PM, Levi Morrison wrote: >> Hmm. > > Thanks. I applied it yesterday and merged to 'next' for testing: > > Features: Record standards and features for Intel C++ on UNIX > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=117d49b8 > > However, it fails the Module.WriteCompilerDetectionHeader test: > > https://open.cdash.org/testDetails.php?test=396604477&build=4124323 > > For now I reverted it from 'next' until we address this failure. > > The WriteCompilerDetectionHeader module and its test need updates > to record support for the Intel compiler features. > > Thanks, > -Brad > I am having trouble reproducing this failure. When I do an unrestricted ctest (test everything) it will fail, but if I do something like `ctest -VV -R WriteCompilerDetectionHeader` it will pass. Any ideas? From brad.king at kitware.com Tue Dec 1 13:11:31 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 1 Dec 2015 13:11:31 -0500 Subject: [cmake-developers] Add CXX_STANDARD support for Intel C++ compilers In-Reply-To: References: <564B9E45.6090002@kitware.com> <564CAB28.9020101@kitware.com> <564CDA4F.9070503@kitware.com> <564DED8E.1030907@kitware.com> <565C9683.6060209@kitware.com> <565DAAAC.3010108@kitware.com> Message-ID: <565DE2D3.6090807@kitware.com> On 12/01/2015 12:47 PM, Levi Morrison wrote: > I am having trouble reproducing this failure. When I do an > unrestricted ctest (test everything) it will fail, but if I do > something like `ctest -VV -R WriteCompilerDetectionHeader` it will > pass. Any ideas? Try ensuring that it is a fresh run of the test: $ rm -rf Tests/Module/WriteCompilerDetectionHeader $ ctest -R Module.WriteCompilerDetectionHeader -V The 'RunCMake' tests always run fresh, but many others are incremental. -Brad From dan at su-root.co.uk Tue Dec 1 14:41:44 2015 From: dan at su-root.co.uk (Dan Liew) Date: Tue, 1 Dec 2015 19:41:44 +0000 Subject: [cmake-developers] [CMake] Obtaining header file dependencies of a source file manually In-Reply-To: <565C9EA1.8020704@kitware.com> References: <565C96E1.1000205@kitware.com> <565C9EA1.8020704@kitware.com> Message-ID: >> There is an alternative which I suggested in the post. Have CMake >> determine the dependencies of the files passed to ``IMPLICIT_DEPENDS`` >> at configure time and spit that into the build files of the generator >> (that would work for any generator). Then have any changes made to the >> files passed to ``IMPLICIT_DEPENDS`` trigger a reconfigure so that the >> dependencies can be recomputed. > > Perhaps, but after regenerating the project the build tool will not > re-load the build files and start building again. That will take > an additional invocation. The number of iterations required is > bounded only by the depth of dependency chains. I don't understand what you mean. What do you mean by "build tool" here? I also don't see why you would need to reconfigure multiple times. From dan at su-root.co.uk Tue Dec 1 14:53:25 2015 From: dan at su-root.co.uk (Dan Liew) Date: Tue, 1 Dec 2015 19:53:25 +0000 Subject: [cmake-developers] Obtaining header file dependencies of a source file manually In-Reply-To: References: Message-ID: > I fail to see why that should not work. Producing LLVM bitcode from > C++ with Clang is just adding -emit-llvm flag, right? So, why can't > the SuperBuild configure the child build to use Clang and this flag? > And Bob's your uncle... Hmm, to be honest I hadn't tried. It works better than expected but... The problem for this particular project is that it doesn't file a very standard compilation process. It compiles to LLVM IR, then to LLVM bitcode and then it invokes and external program to generate source files with the LLVM bitcode embedded in specially named arrays these generated source files then are compiled along with other sources into the projects main library. If I made the external project create OBJECT libraries rather than regular libraries then that might work but when I add the ``-emit-llvm`` flag to CMAKE_C_FLAGS things start breaking..., e.g. ``` include(CheckCCompilerFlag) CHECK_C_COMPILER_FLAG("-g" SUPPORTS_DEBUG) ``` Checking this compiler flag fails if CMAKE_C_FLAGS contains ``-emit-llvm`` due to linking errors. I also need a way of communicating to the outside world where the object files are as they are the final output. Using ``add_library(foo OBJECT ...)`` is just a hack to avoid invoking the linker. Maybe I should use a tool-chain file? I've never used this feature of CMake before but perhaps that would solve these problems. That way I could have CMake use, llvm-link rather than the system linker. Then things wouldn't break when trying to link. Dan. From brad.king at kitware.com Tue Dec 1 14:56:52 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 1 Dec 2015 14:56:52 -0500 Subject: [cmake-developers] [CMake] Obtaining header file dependencies of a source file manually In-Reply-To: References: <565C96E1.1000205@kitware.com> <565C9EA1.8020704@kitware.com> Message-ID: <565DFB84.1040809@kitware.com> On 12/01/2015 02:41 PM, Dan Liew wrote: >> Perhaps, but after regenerating the project the build tool will not >> re-load the build files and start building again. That will take >> an additional invocation. The number of iterations required is >> bounded only by the depth of dependency chains. > > I don't understand what you mean. What do you mean by "build tool" here? > I also don't see why you would need to reconfigure multiple times. If a .vcxproj file is re-generated while "msbuild" is running then the new one may not be loaded and used until the next "msbuild". Perhaps that is okay for this use-case, but dynamic dependency injection is not possible if the dependencies are needed the first time around (which was the case last time I thought about this). Perhaps IMPLICIT_DEPENDS could be implemented by outputting the dependency information as a side effect of running the custom command. Then as part of deciding whether CMake needs to re-run on the next build it can look to see if that dependency information was updated. -Brad From mantis at public.kitware.com Tue Dec 1 15:11:48 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 1 Dec 2015 15:11:48 -0500 Subject: [cmake-developers] [CMake 0015869]: g++ from MinGw check already failes Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15869 ====================================================================== Reported By: Igor Mironchik Assigned To: ====================================================================== Project: CMake Issue ID: 15869 Category: CMake Reproducibility: always Severity: major Priority: high Status: new ====================================================================== Date Submitted: 2015-12-01 15:11 EST Last Modified: 2015-12-01 15:11 EST ====================================================================== Summary: g++ from MinGw check already failes Description: g++ compiler from MinGw check already failes. MinGw version is 2013072200, just downloaded Steps to Reproduce: Clone GoogleTest repository. Run cmake -G "MinGW Makefiles" Additional Information: d:\work\googletest>cmake -G "MinGW Makefiles" -- The CXX compiler identification is unknown -- Check for working CXX compiler: C:/MinGW/bin/g++.exe -- Check for working CXX compiler: C:/MinGW/bin/g++.exe -- broken CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.4/Modules/CMakeTestCXX Compiler.cmake:54 (message): The C++ compiler "C:/MinGW/bin/g++.exe" is not able to compile a simple test program. It fails with the following output: Change Dir: D:/work/googletest/CMakeFiles/CMakeTmp Run Build Command:"C:/MinGW/bin/mingw32-make.exe" "cmTC_3b719/fast" C:/MinGW/bin/mingw32-make.exe -f CMakeFiles\cmTC_3b719.dir\build.make CMakeFiles/cmTC_3b719.dir/build mingw32-make.exe[1]: Entering directory 'D:/work/googletest/CMakeFiles/CMakeTmp' Building CXX object CMakeFiles/cmTC_3b719.dir/testCXXCompiler.cxx.obj C:\MinGW\bin\g++.exe -o CMakeFiles\cmTC_3b719.dir\testCXXCompiler.cxx.obj -c D:\work\googletest\CMakeFiles\CMakeTmp\testCXXCompiler.cxx g++.exe: error: CreateProcess: No such file or directory CMakeFiles\cmTC_3b719.dir\build.make:64: recipe for target 'CMakeFiles/cmTC_3b719.dir/testCXXCompiler.cxx.obj' failed mingw32-make.exe[1]: *** [CMakeFiles/cmTC_3b719.dir/testCXXCompiler.cxx.obj] Error 1 mingw32-make.exe[1]: Leaving directory 'D:/work/googletest/CMakeFiles/CMakeTmp' Makefile:125: recipe for target 'cmTC_3b719/fast' failed mingw32-make.exe: *** [cmTC_3b719/fast] Error 2 CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:3 (project) -- Configuring incomplete, errors occurred! See also "D:/work/googletest/CMakeFiles/CMakeOutput.log". See also "D:/work/googletest/CMakeFiles/CMakeError.log". d:\work\googletest>g++.exe g++.exe: fatal error: no input files compilation terminated. d:\work\googletest> ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-12-01 15:11 Igor Mironchik New Issue ====================================================================== From rleigh at codelibre.net Tue Dec 1 17:11:16 2015 From: rleigh at codelibre.net (Roger Leigh) Date: Tue, 1 Dec 2015 22:11:16 +0000 Subject: [cmake-developers] [PATCH] FindBoost: Add imported targets In-Reply-To: <565DC874.4000903@kitware.com> References: <04b1182ca36b00d00feeefb7de0e7498.squirrel@g.mail.aa.net.uk> <67B03964-3C58-4949-BC7B-D5E880AA55DE@gmail.com> <5649EA9E.7050300@kitware.com> <18d16f5656fe07593344c5bbc42e3c5f.squirrel@g.mail.aa.net.uk> <565B03BE.3050303@codelibre.net> <565C7A50.6050203@kitware.com> <565C8BFF.6030006@kitware.com> <2fd1d7bbf89718f7d8007e229366b002.squirrel@g.mail.aa.net.uk> <565DC874.4000903@kitware.com> Message-ID: <565E1B04.2000902@codelibre.net> On 01/12/2015 16:19, Brad King wrote: > On 12/01/2015 10:58 AM, rleigh at codelibre.net wrote: oking for it when the version number is high enough. > >> I've attached an updated version of the patch which does this. The >> behaviour is otherwise identical to the earlier patches. It's less awful >> than I expected--the information for many Boost releases was the same so >> it could be reduced in size significantly. This also includes a utility >> script to do the parsing, so it can be potentially used for future Boost >> releases as well. I've run the script against all versions of Boost >> supported by the script, and it's verified with the unit test for some of >> the components. > [snip] >> The dependency parsing handles the case where the component library name >> matches the include directory name. For most cases, this is correct, but >> there are cases marked * where it isn't. These cases require the user to >> request the appropriate component name by hand with find_package (since >> the include directory name isn't a valid component name). For most cases >> we can't make the assumption since e.g. if you use we have >> no idea which serialisation library to use; and if you use we >> don't know which of the math_* libraries you /might/ use. We have to >> leave that up to the user. Likewise for . For these >> libraries we also need to special-case the dependency info since we can't >> easily get it via the headers; currently only mpi_python needed handling >> in this way; the others have no dependencies. > > Great. Please split this up into a few commits, perhaps: > > - Add parsing script, perhaps `Utilities/Scripts/BoostScanDeps.cmake`. > I see it documents in the comments the need for special cases already. > Please also add a comment next to each special case to explain it. > > - Run script to populate the table in FindBoost.cmake. Document in > the commit message the range of versions included. > > - Add imported targets using the now-available tables. Attached. I also attached the BoostScanDeps raw output and after search-and-replace to make into valid cmake conditionals, and then after simplifying where following release dependencies are unchanged, so you can see where the logic in FindBoost comes from. Hope this is all acceptable. Happy to make any further changes as needed. Regards, Roger -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Utilities-Add-BoostScanDeps-script.patch Type: text/x-patch Size: 10593 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-FindBoost-Embed-component-dependency-table.patch Type: text/x-patch Size: 12528 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-FindBoost-Automatically-add-missing-component-depend.patch Type: text/x-patch Size: 3370 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-FindBoost-Add-imported-targets.patch Type: text/x-patch Size: 8365 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Tests-Add-FindBoost-testcase-for-imported-targets.patch Type: text/x-patch Size: 3269 bytes Desc: not available URL: -------------- next part -------------- for version in /home/rleigh/boostsources/*; do cmake -DBOOST_DIR=$version -P Utilities/Scripts/BoostScanDeps.cmake; done -- Scanning /home/rleigh/boostsources/boost_1_33_0 -- set(_Boost_IOSTREAMS_DEPENDENCIES regex thread) -- set(_Boost_REGEX_DEPENDENCIES thread) -- set(_Boost_WAVE_DEPENDENCIES filesystem thread) -- set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -- Scanning /home/rleigh/boostsources/boost_1_33_1 -- set(_Boost_IOSTREAMS_DEPENDENCIES regex thread) -- set(_Boost_REGEX_DEPENDENCIES thread) -- set(_Boost_WAVE_DEPENDENCIES filesystem thread) -- set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -- Scanning /home/rleigh/boostsources/boost_1_34_0 -- set(_Boost_IOSTREAMS_DEPENDENCIES regex thread) -- set(_Boost_REGEX_DEPENDENCIES thread) -- set(_Boost_WAVE_DEPENDENCIES filesystem thread) -- set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -- Scanning /home/rleigh/boostsources/boost_1_34_1 -- set(_Boost_IOSTREAMS_DEPENDENCIES regex thread) -- set(_Boost_REGEX_DEPENDENCIES thread) -- set(_Boost_WAVE_DEPENDENCIES filesystem thread) -- set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -- Scanning /home/rleigh/boostsources/boost_1_35_0 -- set(_Boost_FILESYSTEM_DEPENDENCIES system) -- set(_Boost_IOSTREAMS_DEPENDENCIES regex) -- set(_Boost_MPI_DEPENDENCIES serialization) -- set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) -- set(_Boost_WAVE_DEPENDENCIES filesystem system thread) -- set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -- Scanning /home/rleigh/boostsources/boost_1_36_0 -- set(_Boost_FILESYSTEM_DEPENDENCIES system) -- set(_Boost_IOSTREAMS_DEPENDENCIES regex) -- set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l) -- set(_Boost_MPI_DEPENDENCIES serialization) -- set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) -- set(_Boost_WAVE_DEPENDENCIES filesystem system thread) -- set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -- Scanning /home/rleigh/boostsources/boost_1_37_0 -- set(_Boost_FILESYSTEM_DEPENDENCIES system) -- set(_Boost_IOSTREAMS_DEPENDENCIES regex) -- set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l) -- set(_Boost_MPI_DEPENDENCIES serialization) -- set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) -- set(_Boost_WAVE_DEPENDENCIES filesystem system thread) -- set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -- Scanning /home/rleigh/boostsources/boost_1_38_0 -- set(_Boost_FILESYSTEM_DEPENDENCIES system) -- set(_Boost_IOSTREAMS_DEPENDENCIES regex) -- set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l) -- set(_Boost_MPI_DEPENDENCIES serialization) -- set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) -- set(_Boost_THREAD_DEPENDENCIES date_time) -- set(_Boost_WAVE_DEPENDENCIES filesystem system thread date_time) -- set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -- Scanning /home/rleigh/boostsources/boost_1_39_0 -- set(_Boost_FILESYSTEM_DEPENDENCIES system) -- set(_Boost_IOSTREAMS_DEPENDENCIES regex) -- set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l) -- set(_Boost_MPI_DEPENDENCIES serialization) -- set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) -- set(_Boost_THREAD_DEPENDENCIES date_time) -- set(_Boost_WAVE_DEPENDENCIES filesystem system thread date_time) -- set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -- Scanning /home/rleigh/boostsources/boost_1_40_0 -- set(_Boost_FILESYSTEM_DEPENDENCIES system) -- set(_Boost_IOSTREAMS_DEPENDENCIES regex) -- set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l) -- set(_Boost_MPI_DEPENDENCIES serialization) -- set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) -- set(_Boost_THREAD_DEPENDENCIES date_time) -- set(_Boost_WAVE_DEPENDENCIES filesystem system thread date_time) -- set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -- Scanning /home/rleigh/boostsources/boost_1_41_0 -- set(_Boost_FILESYSTEM_DEPENDENCIES system) -- set(_Boost_IOSTREAMS_DEPENDENCIES regex) -- set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l) -- set(_Boost_MPI_DEPENDENCIES serialization) -- set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) -- set(_Boost_THREAD_DEPENDENCIES date_time) -- set(_Boost_WAVE_DEPENDENCIES filesystem system thread date_time) -- set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -- Scanning /home/rleigh/boostsources/boost_1_42_0 -- set(_Boost_FILESYSTEM_DEPENDENCIES system) -- set(_Boost_IOSTREAMS_DEPENDENCIES regex) -- set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l) -- set(_Boost_MPI_DEPENDENCIES serialization) -- set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) -- set(_Boost_THREAD_DEPENDENCIES date_time) -- set(_Boost_WAVE_DEPENDENCIES filesystem system thread date_time) -- set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -- Scanning /home/rleigh/boostsources/boost_1_43_0 -- set(_Boost_FILESYSTEM_DEPENDENCIES system) -- set(_Boost_IOSTREAMS_DEPENDENCIES regex) -- set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l random) -- set(_Boost_MPI_DEPENDENCIES serialization) -- set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) -- set(_Boost_THREAD_DEPENDENCIES date_time) -- set(_Boost_WAVE_DEPENDENCIES filesystem system thread date_time) -- set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -- Scanning /home/rleigh/boostsources/boost_1_44_0 -- set(_Boost_FILESYSTEM_DEPENDENCIES system) -- set(_Boost_IOSTREAMS_DEPENDENCIES regex) -- set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l random serialization) -- set(_Boost_MPI_DEPENDENCIES serialization) -- set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) -- set(_Boost_THREAD_DEPENDENCIES date_time) -- set(_Boost_WAVE_DEPENDENCIES serialization filesystem system thread date_time) -- set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -- Scanning /home/rleigh/boostsources/boost_1_45_0 -- set(_Boost_FILESYSTEM_DEPENDENCIES system) -- set(_Boost_IOSTREAMS_DEPENDENCIES regex) -- set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l random) -- set(_Boost_MPI_DEPENDENCIES serialization) -- set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) -- set(_Boost_THREAD_DEPENDENCIES date_time) -- set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread date_time) -- set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -- Scanning /home/rleigh/boostsources/boost_1_46_0 -- set(_Boost_FILESYSTEM_DEPENDENCIES system) -- set(_Boost_IOSTREAMS_DEPENDENCIES regex) -- set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l random) -- set(_Boost_MPI_DEPENDENCIES serialization) -- set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) -- set(_Boost_THREAD_DEPENDENCIES date_time) -- set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread date_time) -- set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -- Scanning /home/rleigh/boostsources/boost_1_46_1 -- set(_Boost_FILESYSTEM_DEPENDENCIES system) -- set(_Boost_IOSTREAMS_DEPENDENCIES regex) -- set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l random) -- set(_Boost_MPI_DEPENDENCIES serialization) -- set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) -- set(_Boost_THREAD_DEPENDENCIES date_time) -- set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread date_time) -- set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -- Scanning /home/rleigh/boostsources/boost_1_47_0 -- set(_Boost_CHRONO_DEPENDENCIES system) -- set(_Boost_FILESYSTEM_DEPENDENCIES system) -- set(_Boost_IOSTREAMS_DEPENDENCIES regex) -- set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l random) -- set(_Boost_MPI_DEPENDENCIES serialization) -- set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) -- set(_Boost_THREAD_DEPENDENCIES date_time) -- set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread date_time) -- set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -- Scanning /home/rleigh/boostsources/boost_1_48_0 -- set(_Boost_CHRONO_DEPENDENCIES system) -- set(_Boost_FILESYSTEM_DEPENDENCIES system) -- set(_Boost_IOSTREAMS_DEPENDENCIES regex) -- set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l random) -- set(_Boost_MPI_DEPENDENCIES serialization) -- set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) -- set(_Boost_THREAD_DEPENDENCIES date_time) -- set(_Boost_TIMER_DEPENDENCIES chrono system) -- set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread date_time) -- set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -- Scanning /home/rleigh/boostsources/boost_1_49_0 -- set(_Boost_CHRONO_DEPENDENCIES system) -- set(_Boost_FILESYSTEM_DEPENDENCIES system) -- set(_Boost_IOSTREAMS_DEPENDENCIES regex) -- set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l random) -- set(_Boost_MPI_DEPENDENCIES serialization) -- set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) -- set(_Boost_THREAD_DEPENDENCIES date_time) -- set(_Boost_TIMER_DEPENDENCIES chrono system) -- set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread date_time) -- set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -- Scanning /home/rleigh/boostsources/boost_1_50_0 -- set(_Boost_CHRONO_DEPENDENCIES system) -- set(_Boost_FILESYSTEM_DEPENDENCIES system) -- set(_Boost_IOSTREAMS_DEPENDENCIES regex) -- set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l regex random) -- set(_Boost_MPI_DEPENDENCIES serialization) -- set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) -- set(_Boost_THREAD_DEPENDENCIES chrono system date_time) -- set(_Boost_TIMER_DEPENDENCIES chrono system) -- set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono date_time) -- set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -- Scanning /home/rleigh/boostsources/boost_1_51_0 -- set(_Boost_CHRONO_DEPENDENCIES system) -- set(_Boost_FILESYSTEM_DEPENDENCIES system) -- set(_Boost_IOSTREAMS_DEPENDENCIES regex) -- set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l regex random) -- set(_Boost_MPI_DEPENDENCIES serialization) -- set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) -- set(_Boost_THREAD_DEPENDENCIES chrono system date_time) -- set(_Boost_TIMER_DEPENDENCIES chrono system) -- set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono date_time) -- set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -- Scanning /home/rleigh/boostsources/boost_1_52_0 -- set(_Boost_CHRONO_DEPENDENCIES system) -- set(_Boost_FILESYSTEM_DEPENDENCIES system) -- set(_Boost_IOSTREAMS_DEPENDENCIES regex) -- set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l regex random) -- set(_Boost_MPI_DEPENDENCIES serialization) -- set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) -- set(_Boost_THREAD_DEPENDENCIES chrono system date_time) -- set(_Boost_TIMER_DEPENDENCIES chrono system) -- set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono date_time) -- set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -- Scanning /home/rleigh/boostsources/boost_1_53_0 -- set(_Boost_ATOMIC_DEPENDENCIES thread chrono system date_time) -- set(_Boost_CHRONO_DEPENDENCIES system) -- set(_Boost_FILESYSTEM_DEPENDENCIES system) -- set(_Boost_IOSTREAMS_DEPENDENCIES regex) -- set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l regex random) -- set(_Boost_MPI_DEPENDENCIES serialization) -- set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) -- set(_Boost_THREAD_DEPENDENCIES chrono system date_time atomic) -- set(_Boost_TIMER_DEPENDENCIES chrono system) -- set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono date_time) -- set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -- Scanning /home/rleigh/boostsources/boost_1_54_0 -- set(_Boost_ATOMIC_DEPENDENCIES thread chrono system date_time) -- set(_Boost_CHRONO_DEPENDENCIES system) -- set(_Boost_FILESYSTEM_DEPENDENCIES system) -- set(_Boost_IOSTREAMS_DEPENDENCIES regex) -- set(_Boost_LOG_DEPENDENCIES log_setup date_time system filesystem thread regex chrono) -- set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l regex random) -- set(_Boost_MPI_DEPENDENCIES serialization) -- set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) -- set(_Boost_THREAD_DEPENDENCIES chrono system date_time atomic) -- set(_Boost_TIMER_DEPENDENCIES chrono system) -- set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono date_time atomic) -- set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -- Scanning /home/rleigh/boostsources/boost_1_55_0 -- set(_Boost_CHRONO_DEPENDENCIES system) -- set(_Boost_COROUTINE_DEPENDENCIES context system) -- set(_Boost_FILESYSTEM_DEPENDENCIES system) -- set(_Boost_IOSTREAMS_DEPENDENCIES regex) -- set(_Boost_LOG_DEPENDENCIES log_setup date_time system filesystem thread regex chrono) -- set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l regex random) -- set(_Boost_MPI_DEPENDENCIES serialization) -- set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) -- set(_Boost_THREAD_DEPENDENCIES chrono system date_time atomic) -- set(_Boost_TIMER_DEPENDENCIES chrono system) -- set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono date_time atomic) -- set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -- Scanning /home/rleigh/boostsources/boost_1_56_0 -- set(_Boost_CHRONO_DEPENDENCIES system) -- set(_Boost_COROUTINE_DEPENDENCIES context system) -- set(_Boost_FILESYSTEM_DEPENDENCIES system) -- set(_Boost_IOSTREAMS_DEPENDENCIES regex) -- set(_Boost_LOG_DEPENDENCIES log_setup date_time system filesystem thread regex chrono) -- set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l atomic) -- set(_Boost_MPI_DEPENDENCIES serialization) -- set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) -- set(_Boost_RANDOM_DEPENDENCIES system) -- set(_Boost_THREAD_DEPENDENCIES chrono system date_time atomic) -- set(_Boost_TIMER_DEPENDENCIES chrono system) -- set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono date_time atomic) -- set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -- Scanning /home/rleigh/boostsources/boost_1_57_0 -- set(_Boost_CHRONO_DEPENDENCIES system) -- set(_Boost_COROUTINE_DEPENDENCIES context system) -- set(_Boost_FILESYSTEM_DEPENDENCIES system) -- set(_Boost_IOSTREAMS_DEPENDENCIES regex) -- set(_Boost_LOG_DEPENDENCIES log_setup date_time system filesystem thread regex chrono) -- set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l atomic) -- set(_Boost_MPI_DEPENDENCIES serialization) -- set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) -- set(_Boost_RANDOM_DEPENDENCIES system) -- set(_Boost_THREAD_DEPENDENCIES chrono system date_time atomic) -- set(_Boost_TIMER_DEPENDENCIES chrono system) -- set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono date_time atomic) -- set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -- Scanning /home/rleigh/boostsources/boost_1_58_0 -- set(_Boost_CHRONO_DEPENDENCIES system) -- set(_Boost_COROUTINE_DEPENDENCIES context system) -- set(_Boost_FILESYSTEM_DEPENDENCIES system) -- set(_Boost_IOSTREAMS_DEPENDENCIES regex) -- set(_Boost_LOG_DEPENDENCIES log_setup date_time system filesystem thread regex chrono) -- set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l atomic) -- set(_Boost_MPI_DEPENDENCIES serialization) -- set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) -- set(_Boost_RANDOM_DEPENDENCIES system) -- set(_Boost_THREAD_DEPENDENCIES chrono system date_time atomic) -- set(_Boost_TIMER_DEPENDENCIES chrono system) -- set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono date_time atomic) -- set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -- Scanning /home/rleigh/boostsources/boost_1_59_0 -- set(_Boost_CHRONO_DEPENDENCIES system) -- set(_Boost_COROUTINE_DEPENDENCIES context system) -- set(_Boost_FILESYSTEM_DEPENDENCIES system) -- set(_Boost_IOSTREAMS_DEPENDENCIES regex) -- set(_Boost_LOG_DEPENDENCIES log_setup date_time system filesystem thread regex chrono atomic) -- set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l atomic) -- set(_Boost_MPI_DEPENDENCIES serialization) -- set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) -- set(_Boost_RANDOM_DEPENDENCIES system) -- set(_Boost_THREAD_DEPENDENCIES chrono system date_time atomic) -- set(_Boost_TIMER_DEPENDENCIES chrono system) -- set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono date_time atomic) -- set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -------------- next part -------------- if(NOT Boost_VERSION VERSION_LESS 103300 AND Boost_VERSION VERSION_LESS 103301) set(_Boost_IOSTREAMS_DEPENDENCIES regex thread) set(_Boost_REGEX_DEPENDENCIES thread) set(_Boost_WAVE_DEPENDENCIES filesystem thread) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 103301 AND Boost_VERSION VERSION_LESS 103400) set(_Boost_IOSTREAMS_DEPENDENCIES regex thread) set(_Boost_REGEX_DEPENDENCIES thread) set(_Boost_WAVE_DEPENDENCIES filesystem thread) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 103400 AND Boost_VERSION VERSION_LESS 103401) set(_Boost_IOSTREAMS_DEPENDENCIES regex thread) set(_Boost_REGEX_DEPENDENCIES thread) set(_Boost_WAVE_DEPENDENCIES filesystem thread) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 103401 AND Boost_VERSION VERSION_LESS 103500) set(_Boost_IOSTREAMS_DEPENDENCIES regex thread) set(_Boost_REGEX_DEPENDENCIES thread) set(_Boost_WAVE_DEPENDENCIES filesystem thread) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 103500 AND Boost_VERSION VERSION_LESS 103600) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_WAVE_DEPENDENCIES filesystem system thread) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 103600 AND Boost_VERSION VERSION_LESS 103700) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_WAVE_DEPENDENCIES filesystem system thread) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 103700 AND Boost_VERSION VERSION_LESS 103800) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_WAVE_DEPENDENCIES filesystem system thread) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 103800 AND Boost_VERSION VERSION_LESS 103900) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_THREAD_DEPENDENCIES date_time) set(_Boost_WAVE_DEPENDENCIES filesystem system thread date_time) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 103900 AND Boost_VERSION VERSION_LESS 104000) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_THREAD_DEPENDENCIES date_time) set(_Boost_WAVE_DEPENDENCIES filesystem system thread date_time) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 104000 AND Boost_VERSION VERSION_LESS 104100) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_THREAD_DEPENDENCIES date_time) set(_Boost_WAVE_DEPENDENCIES filesystem system thread date_time) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 104100 AND Boost_VERSION VERSION_LESS 104200) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_THREAD_DEPENDENCIES date_time) set(_Boost_WAVE_DEPENDENCIES filesystem system thread date_time) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 104200 AND Boost_VERSION VERSION_LESS 104300) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_THREAD_DEPENDENCIES date_time) set(_Boost_WAVE_DEPENDENCIES filesystem system thread date_time) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 104300 AND Boost_VERSION VERSION_LESS 104400) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l random) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_THREAD_DEPENDENCIES date_time) set(_Boost_WAVE_DEPENDENCIES filesystem system thread date_time) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 104400 AND Boost_VERSION VERSION_LESS 104500) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l random serialization) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_THREAD_DEPENDENCIES date_time) set(_Boost_WAVE_DEPENDENCIES serialization filesystem system thread date_time) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 104500 AND Boost_VERSION VERSION_LESS 104600) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l random) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_THREAD_DEPENDENCIES date_time) set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread date_time) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 104600 AND Boost_VERSION VERSION_LESS 104601) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l random) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_THREAD_DEPENDENCIES date_time) set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread date_time) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 104601 AND Boost_VERSION VERSION_LESS 104700) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l random) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_THREAD_DEPENDENCIES date_time) set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread date_time) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 104700 AND Boost_VERSION VERSION_LESS 104800) set(_Boost_CHRONO_DEPENDENCIES system) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l random) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_THREAD_DEPENDENCIES date_time) set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread date_time) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 104800 AND Boost_VERSION VERSION_LESS 104900) set(_Boost_CHRONO_DEPENDENCIES system) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l random) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_THREAD_DEPENDENCIES date_time) set(_Boost_TIMER_DEPENDENCIES chrono system) set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread date_time) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 104900 AND Boost_VERSION VERSION_LESS 105000) set(_Boost_CHRONO_DEPENDENCIES system) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l random) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_THREAD_DEPENDENCIES date_time) set(_Boost_TIMER_DEPENDENCIES chrono system) set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread date_time) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 105000 AND Boost_VERSION VERSION_LESS 105100) set(_Boost_CHRONO_DEPENDENCIES system) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l regex random) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_THREAD_DEPENDENCIES chrono system date_time) set(_Boost_TIMER_DEPENDENCIES chrono system) set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono date_time) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 105100 AND Boost_VERSION VERSION_LESS 105200) set(_Boost_CHRONO_DEPENDENCIES system) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l regex random) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_THREAD_DEPENDENCIES chrono system date_time) set(_Boost_TIMER_DEPENDENCIES chrono system) set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono date_time) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 105200 AND Boost_VERSION VERSION_LESS 105300) set(_Boost_CHRONO_DEPENDENCIES system) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l regex random) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_THREAD_DEPENDENCIES chrono system date_time) set(_Boost_TIMER_DEPENDENCIES chrono system) set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono date_time) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 105300 AND Boost_VERSION VERSION_LESS 105400) set(_Boost_ATOMIC_DEPENDENCIES thread chrono system date_time) set(_Boost_CHRONO_DEPENDENCIES system) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l regex random) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_THREAD_DEPENDENCIES chrono system date_time atomic) set(_Boost_TIMER_DEPENDENCIES chrono system) set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono date_time) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 105400 AND Boost_VERSION VERSION_LESS 105500) set(_Boost_ATOMIC_DEPENDENCIES thread chrono system date_time) set(_Boost_CHRONO_DEPENDENCIES system) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_LOG_DEPENDENCIES log_setup date_time system filesystem thread regex chrono) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l regex random) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_THREAD_DEPENDENCIES chrono system date_time atomic) set(_Boost_TIMER_DEPENDENCIES chrono system) set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono date_time atomic) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 105500 AND Boost_VERSION VERSION_LESS 105600) set(_Boost_CHRONO_DEPENDENCIES system) set(_Boost_COROUTINE_DEPENDENCIES context system) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_LOG_DEPENDENCIES log_setup date_time system filesystem thread regex chrono) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l regex random) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_THREAD_DEPENDENCIES chrono system date_time atomic) set(_Boost_TIMER_DEPENDENCIES chrono system) set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono date_time atomic) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 105600 AND Boost_VERSION VERSION_LESS 105700) set(_Boost_CHRONO_DEPENDENCIES system) set(_Boost_COROUTINE_DEPENDENCIES context system) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_LOG_DEPENDENCIES log_setup date_time system filesystem thread regex chrono) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l atomic) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_RANDOM_DEPENDENCIES system) set(_Boost_THREAD_DEPENDENCIES chrono system date_time atomic) set(_Boost_TIMER_DEPENDENCIES chrono system) set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono date_time atomic) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 105700 AND Boost_VERSION VERSION_LESS 105800) set(_Boost_CHRONO_DEPENDENCIES system) set(_Boost_COROUTINE_DEPENDENCIES context system) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_LOG_DEPENDENCIES log_setup date_time system filesystem thread regex chrono) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l atomic) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_RANDOM_DEPENDENCIES system) set(_Boost_THREAD_DEPENDENCIES chrono system date_time atomic) set(_Boost_TIMER_DEPENDENCIES chrono system) set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono date_time atomic) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 105800 AND Boost_VERSION VERSION_LESS 105900) set(_Boost_CHRONO_DEPENDENCIES system) set(_Boost_COROUTINE_DEPENDENCIES context system) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_LOG_DEPENDENCIES log_setup date_time system filesystem thread regex chrono) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l atomic) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_RANDOM_DEPENDENCIES system) set(_Boost_THREAD_DEPENDENCIES chrono system date_time atomic) set(_Boost_TIMER_DEPENDENCIES chrono system) set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono date_time atomic) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 105900 AND Boost_VERSION VERSION_LESS 106000) set(_Boost_CHRONO_DEPENDENCIES system) set(_Boost_COROUTINE_DEPENDENCIES context system) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_LOG_DEPENDENCIES log_setup date_time system filesystem thread regex chrono atomic) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l atomic) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_RANDOM_DEPENDENCIES system) set(_Boost_THREAD_DEPENDENCIES chrono system date_time atomic) set(_Boost_TIMER_DEPENDENCIES chrono system) set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono date_time atomic) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) -------------- next part -------------- if(NOT Boost_VERSION VERSION_LESS 103300 AND Boost_VERSION VERSION_LESS 103500) set(_Boost_IOSTREAMS_DEPENDENCIES regex thread) set(_Boost_REGEX_DEPENDENCIES thread) set(_Boost_WAVE_DEPENDENCIES filesystem thread) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 103500 AND Boost_VERSION VERSION_LESS 103600) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_WAVE_DEPENDENCIES filesystem system thread) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 103600 AND Boost_VERSION VERSION_LESS 103800) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_WAVE_DEPENDENCIES filesystem system thread) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 103800 AND Boost_VERSION VERSION_LESS 104300) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_THREAD_DEPENDENCIES date_time) set(_Boost_WAVE_DEPENDENCIES filesystem system thread date_time) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 104300 AND Boost_VERSION VERSION_LESS 104400) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l random) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_THREAD_DEPENDENCIES date_time) set(_Boost_WAVE_DEPENDENCIES filesystem system thread date_time) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 104400 AND Boost_VERSION VERSION_LESS 104500) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l random serialization) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_THREAD_DEPENDENCIES date_time) set(_Boost_WAVE_DEPENDENCIES serialization filesystem system thread date_time) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 104500 AND Boost_VERSION VERSION_LESS 104700) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l random) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_THREAD_DEPENDENCIES date_time) set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread date_time) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 104700 AND Boost_VERSION VERSION_LESS 104800) set(_Boost_CHRONO_DEPENDENCIES system) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l random) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_THREAD_DEPENDENCIES date_time) set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread date_time) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 104800 AND Boost_VERSION VERSION_LESS 105000) set(_Boost_CHRONO_DEPENDENCIES system) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l random) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_THREAD_DEPENDENCIES date_time) set(_Boost_TIMER_DEPENDENCIES chrono system) set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread date_time) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 105000 AND Boost_VERSION VERSION_LESS 105300) set(_Boost_CHRONO_DEPENDENCIES system) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l regex random) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_THREAD_DEPENDENCIES chrono system date_time) set(_Boost_TIMER_DEPENDENCIES chrono system) set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono date_time) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 105300 AND Boost_VERSION VERSION_LESS 105400) set(_Boost_ATOMIC_DEPENDENCIES thread chrono system date_time) set(_Boost_CHRONO_DEPENDENCIES system) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l regex random) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_THREAD_DEPENDENCIES chrono system date_time atomic) set(_Boost_TIMER_DEPENDENCIES chrono system) set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono date_time) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 105400 AND Boost_VERSION VERSION_LESS 105500) set(_Boost_ATOMIC_DEPENDENCIES thread chrono system date_time) set(_Boost_CHRONO_DEPENDENCIES system) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_LOG_DEPENDENCIES log_setup date_time system filesystem thread regex chrono) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l regex random) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_THREAD_DEPENDENCIES chrono system date_time atomic) set(_Boost_TIMER_DEPENDENCIES chrono system) set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono date_time atomic) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 105500 AND Boost_VERSION VERSION_LESS 105600) set(_Boost_CHRONO_DEPENDENCIES system) set(_Boost_COROUTINE_DEPENDENCIES context system) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_LOG_DEPENDENCIES log_setup date_time system filesystem thread regex chrono) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l regex random) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_THREAD_DEPENDENCIES chrono system date_time atomic) set(_Boost_TIMER_DEPENDENCIES chrono system) set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono date_time atomic) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 105600 AND Boost_VERSION VERSION_LESS 105900) set(_Boost_CHRONO_DEPENDENCIES system) set(_Boost_COROUTINE_DEPENDENCIES context system) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_LOG_DEPENDENCIES log_setup date_time system filesystem thread regex chrono) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l atomic) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_RANDOM_DEPENDENCIES system) set(_Boost_THREAD_DEPENDENCIES chrono system date_time atomic) set(_Boost_TIMER_DEPENDENCIES chrono system) set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono date_time atomic) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) elseif(NOT Boost_VERSION VERSION_LESS 105900 AND Boost_VERSION VERSION_LESS 106000) set(_Boost_CHRONO_DEPENDENCIES system) set(_Boost_COROUTINE_DEPENDENCIES context system) set(_Boost_FILESYSTEM_DEPENDENCIES system) set(_Boost_IOSTREAMS_DEPENDENCIES regex) set(_Boost_LOG_DEPENDENCIES log_setup date_time system filesystem thread regex chrono atomic) set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l atomic) set(_Boost_MPI_DEPENDENCIES serialization) set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization) set(_Boost_RANDOM_DEPENDENCIES system) set(_Boost_THREAD_DEPENDENCIES chrono system date_time atomic) set(_Boost_TIMER_DEPENDENCIES chrono system) set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono date_time atomic) set(_Boost_WSERIALIZATION_DEPENDENCIES serialization) From Bartosz.Kosiorek at tomtom.com Wed Dec 2 07:44:31 2015 From: Bartosz.Kosiorek at tomtom.com (Bartosz Kosiorek) Date: Wed, 2 Dec 2015 12:44:31 +0000 Subject: [cmake-developers] Fw: Please comment on ios-universal topic In-Reply-To: <1449054144180.13106@tomtom.com> References: <565DAD1B.60301@googlemail.com>,<1449054144180.13106@tomtom.com> Message-ID: <1449060271344.76735@tomtom.com> Hi. Currently we already support similar target properties: - INSTALL_NAME_DIR - INSTALL_RPATH - INSTALL_RPATH_USE_LINK_PATH It will be great to follow the same name convention. Because this new property is only applicable for INSTALL step, I would like to propose to rename property name to INSTALL_IOS_UNIVERSAL_LIBS. What do you think about that idea? ________________________________________ From: cmake-developers on behalf of Gregor Jasny via cmake-developers Sent: Tuesday, December 1, 2015 3:22 PM To: CMake Developers; Ruslan Baratov Subject: [cmake-developers] Please comment on ios-universal topic Hello, During the last days I worked on the iOS Universal Install topic which now would benefit from a review. Especially the core changes could need a third pair of eyes: https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=8fb23b42cfc2fb7490e8645fff328add9c231713 I will now concentrate on adding more tests during the next days. Thank you, Gregor -- 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 From brad.king at kitware.com Wed Dec 2 09:10:10 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 2 Dec 2015 09:10:10 -0500 Subject: [cmake-developers] [PATCH] FindBoost: Add imported targets In-Reply-To: <565E1B04.2000902@codelibre.net> References: <04b1182ca36b00d00feeefb7de0e7498.squirrel@g.mail.aa.net.uk> <67B03964-3C58-4949-BC7B-D5E880AA55DE@gmail.com> <5649EA9E.7050300@kitware.com> <18d16f5656fe07593344c5bbc42e3c5f.squirrel@g.mail.aa.net.uk> <565B03BE.3050303@codelibre.net> <565C7A50.6050203@kitware.com> <565C8BFF.6030006@kitware.com> <2fd1d7bbf89718f7d8007e229366b002.squirrel@g.mail.aa.net.uk> <565DC874.4000903@kitware.com> <565E1B04.2000902@codelibre.net> Message-ID: <565EFBC2.30401@kitware.com> On 12/01/2015 05:11 PM, Roger Leigh wrote: > Attached. I also attached the BoostScanDeps raw output and after > search-and-replace to make into valid cmake conditionals, and then after > simplifying where following release dependencies are unchanged, so you > can see where the logic in FindBoost comes from. Thanks. That is a nice breakdown. Please revies the "FindBoost: Embed component dependency table" commit message to explain the steps used to run the script and ultimately get the content added by the commit. > + # Note: When adding a new Boost release, also update the dependency > + # information in _Boost_COMPONENT_DEPENDENCIES This is a good note. Please extend it with a reference to instructions somewhere on how to actually perform the update. Thanks, -Brad From rleigh at codelibre.net Wed Dec 2 09:34:59 2015 From: rleigh at codelibre.net (rleigh at codelibre.net) Date: Wed, 2 Dec 2015 14:34:59 -0000 (GMT) Subject: [cmake-developers] [PATCH] FindBoost: Add imported targets In-Reply-To: <565EFBC2.30401@kitware.com> References: <04b1182ca36b00d00feeefb7de0e7498.squirrel@g.mail.aa.net.uk> <67B03964-3C58-4949-BC7B-D5E880AA55DE@gmail.com> <5649EA9E.7050300@kitware.com> <18d16f5656fe07593344c5bbc42e3c5f.squirrel@g.mail.aa.net.uk> <565B03BE.3050303@codelibre.net> <565C7A50.6050203@kitware.com> <565C8BFF.6030006@kitware.com> <2fd1d7bbf89718f7d8007e229366b002.squirrel@g.mail.aa.net.uk> <565DC874.4000903@kitware.com> <565E1B04.2000902@codelibre.net> <565EFBC2.30401@kitware.com> Message-ID: > On 12/01/2015 05:11 PM, Roger Leigh wrote: >> Attached. I also attached the BoostScanDeps raw output and after >> search-and-replace to make into valid cmake conditionals, and then after >> simplifying where following release dependencies are unchanged, so you >> can see where the logic in FindBoost comes from. > > Thanks. That is a nice breakdown. > > Please revies the "FindBoost: Embed component dependency table" commit > message to explain the steps used to run the script and ultimately get > the content added by the commit. > >> + # Note: When adding a new Boost release, also update the dependency >> + # information in _Boost_COMPONENT_DEPENDENCIES > > This is a good note. Please extend it with a reference to instructions > somewhere on how to actually perform the update. I have updated both as requested, please find the updated patch attached. Regards, Roger -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-FindBoost-Embed-component-dependency-table.patch Type: text/x-diff Size: 13975 bytes Desc: not available URL: From brad.king at kitware.com Wed Dec 2 09:47:33 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 2 Dec 2015 09:47:33 -0500 Subject: [cmake-developers] [PATCH] FindBoost: Add imported targets In-Reply-To: References: <04b1182ca36b00d00feeefb7de0e7498.squirrel@g.mail.aa.net.uk> <67B03964-3C58-4949-BC7B-D5E880AA55DE@gmail.com> <5649EA9E.7050300@kitware.com> <18d16f5656fe07593344c5bbc42e3c5f.squirrel@g.mail.aa.net.uk> <565B03BE.3050303@codelibre.net> <565C7A50.6050203@kitware.com> <565C8BFF.6030006@kitware.com> <2fd1d7bbf89718f7d8007e229366b002.squirrel@g.mail.aa.net.uk> <565DC874.4000903@kitware.com> <565E1B04.2000902@codelibre.net> <565EFBC2.30401@kitware.com> Message-ID: <565F0485.4070109@kitware.com> On 12/02/2015 09:34 AM, rleigh at codelibre.net wrote: > I have updated both as requested, please find the updated patch attached. Great. I've merged the topic to 'next' for testing: Merge topic 'FindBoost-imported-targets' into next https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e5ecb126 I also enabled CMake_TEST_FindBoost on a dashboard machine that has Boost installed. Thanks, -Brad From morrison.levi at gmail.com Wed Dec 2 10:31:41 2015 From: morrison.levi at gmail.com (Levi Morrison) Date: Wed, 2 Dec 2015 08:31:41 -0700 Subject: [cmake-developers] Add CXX_STANDARD support for Intel C++ compilers In-Reply-To: <565DE2D3.6090807@kitware.com> References: <564B9E45.6090002@kitware.com> <564CAB28.9020101@kitware.com> <564CDA4F.9070503@kitware.com> <564DED8E.1030907@kitware.com> <565C9683.6060209@kitware.com> <565DAAAC.3010108@kitware.com> <565DE2D3.6090807@kitware.com> Message-ID: On Tue, Dec 1, 2015 at 11:11 AM, Brad King wrote: > On 12/01/2015 12:47 PM, Levi Morrison wrote: >> I am having trouble reproducing this failure. When I do an >> unrestricted ctest (test everything) it will fail, but if I do >> something like `ctest -VV -R WriteCompilerDetectionHeader` it will >> pass. Any ideas? > > Try ensuring that it is a fresh run of the test: > > $ rm -rf Tests/Module/WriteCompilerDetectionHeader > $ ctest -R Module.WriteCompilerDetectionHeader -V > > The 'RunCMake' tests always run fresh, but many others are > incremental. > > -Brad > Hmm. What is the purpose of this module? I verified that indeed my changeset somehow breaks this test but I don't even understand what it is trying to do. At a glance it looks like even *more* duplication of feature detection. Please tell me I'm wrong. From brad.king at kitware.com Wed Dec 2 10:40:31 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 2 Dec 2015 10:40:31 -0500 Subject: [cmake-developers] Add CXX_STANDARD support for Intel C++ compilers In-Reply-To: References: <564CAB28.9020101@kitware.com> <564CDA4F.9070503@kitware.com> <564DED8E.1030907@kitware.com> <565C9683.6060209@kitware.com> <565DAAAC.3010108@kitware.com> <565DE2D3.6090807@kitware.com> Message-ID: <565F10EF.4000609@kitware.com> On 12/02/2015 10:31 AM, Levi Morrison wrote: > Hmm. What is the purpose of this module? I verified that indeed my > changeset somehow breaks this test but I don't even understand what it > is trying to do. At a glance it looks like even *more* duplication of > feature detection. Please tell me I'm wrong. It re-uses the Modules/Compiler/--FeatureTests.cmake information to generate a header file that projects can include to check for the availability of features. The header can then be installed and re-used by clients of such projects even if they do not use CMake. The test checks that those results are consistent with the features detected by CMake. -Brad From rleigh at codelibre.net Wed Dec 2 12:30:59 2015 From: rleigh at codelibre.net (rleigh at codelibre.net) Date: Wed, 2 Dec 2015 17:30:59 -0000 (GMT) Subject: [cmake-developers] [PATCH] FindTIFF: Add imported targets Message-ID: - Add TIFF::TIFF imported target - Document imported target - Add testcase to test the standard variables and the imported target Also: - Add TIFF_INCLUDE_DIRS to match common practice - Update documentation generally, including documenting TIFF_INCLUDE_DIRS Patch attached. Regards, Roger -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-FindTIFF-Add-imported-targets-and-update-documentati.patch Type: text/x-diff Size: 6270 bytes Desc: not available URL: From rleigh at codelibre.net Wed Dec 2 12:31:56 2015 From: rleigh at codelibre.net (rleigh at codelibre.net) Date: Wed, 2 Dec 2015 17:31:56 -0000 (GMT) Subject: [cmake-developers] [PATCH] FindTIFF: Add imported targets Message-ID: <6bef44c4fe63e6eca28c53d712d2c9b4.squirrel@g.mail.aa.net.uk> - Add TIFF::TIFF imported target - Document imported target - Add testcase to test the standard variables and the imported target Also: - Add TIFF_INCLUDE_DIRS to match common practice - Update documentation generally, including documenting TIFF_INCLUDE_DIRS Patch actually attached this time... Regards, Roger -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-FindTIFF-Add-imported-targets-and-update-documentati.patch Type: text/x-diff Size: 6270 bytes Desc: not available URL: From robert.maynard at kitware.com Wed Dec 2 14:54:38 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 2 Dec 2015 14:54:38 -0500 Subject: [cmake-developers] [ANNOUNCE] CMake 3.4.1 available for download Message-ID: We are pleased to announce that CMake 3.4.1 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.4.1 since 3.4.0: Bill Hoffman (1): Fix auto export symbols for Dlls containing /bigobj for 64bit builds. Brad King (23): Cray: Implement Fortran compiler version detection (#15845) MSVC: Fix linking with /MANIFEST:NO option Make C and C++ default dialect detection robust to advanced optimizations FindGTest: Refactor test type checks to avoid cases triggering CMP0064 Android: Restore generation of non-versioned soname (#15851) Project: Guess default standard dialect if compiler was forced (#15852) Revert "Disable shared library support when compiler links statically" (#15855) Tests: Add case for add_subdirectory inside a function Tests: Add case for unmatched cmake_policy({PUSH,POP}) Tests: Add case for package version file unmatched policy scope cmState: Skip variable scope snapshots to avoid call stack duplicates cmMakefile: Clarify purpose of method that pops a scope snapshot cmMakefile: Remove unused PolicyPushPop interfaces cmLocalGenerator: Use ScopePushPop RAII class to manage local variable scopes cmState: Enforce policy scope balancing around variable scopes cmLinkedTree: Rename 'Extend' method to 'Push' cmLinkedTree: Add Pop method cmListFileCache: Implement cmListFileBacktrace ctor/dtor out-of-line cmState: Avoid accumulating policy stack storage for short-lived scopes cmState: Avoid accumulating snapshot storage for short-lived scopes cmOrderDirectories: Factor out directory comparison cmOrderDirectories: Reduce repeat realpath() calls CMake 3.4.1 Kylie McClain (1): Include `sys/types.h` header to get `mode_t` Marek Vasut (1): Add NIOS2 CPU support Ty Smith (1): cmELF: Avoid divide by zero if there are no dynamic section entries From robert.maynard at kitware.com Wed Dec 2 14:54:49 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 2 Dec 2015 14:54:49 -0500 Subject: [cmake-developers] [ANNOUNCE] CMake 3.4.1 available for download Message-ID: We are pleased to announce that CMake 3.4.1 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.4.1 since 3.4.0: Bill Hoffman (1): Fix auto export symbols for Dlls containing /bigobj for 64bit builds. Brad King (23): Cray: Implement Fortran compiler version detection (#15845) MSVC: Fix linking with /MANIFEST:NO option Make C and C++ default dialect detection robust to advanced optimizations FindGTest: Refactor test type checks to avoid cases triggering CMP0064 Android: Restore generation of non-versioned soname (#15851) Project: Guess default standard dialect if compiler was forced (#15852) Revert "Disable shared library support when compiler links statically" (#15855) Tests: Add case for add_subdirectory inside a function Tests: Add case for unmatched cmake_policy({PUSH,POP}) Tests: Add case for package version file unmatched policy scope cmState: Skip variable scope snapshots to avoid call stack duplicates cmMakefile: Clarify purpose of method that pops a scope snapshot cmMakefile: Remove unused PolicyPushPop interfaces cmLocalGenerator: Use ScopePushPop RAII class to manage local variable scopes cmState: Enforce policy scope balancing around variable scopes cmLinkedTree: Rename 'Extend' method to 'Push' cmLinkedTree: Add Pop method cmListFileCache: Implement cmListFileBacktrace ctor/dtor out-of-line cmState: Avoid accumulating policy stack storage for short-lived scopes cmState: Avoid accumulating snapshot storage for short-lived scopes cmOrderDirectories: Factor out directory comparison cmOrderDirectories: Reduce repeat realpath() calls CMake 3.4.1 Kylie McClain (1): Include `sys/types.h` header to get `mode_t` Marek Vasut (1): Add NIOS2 CPU support Ty Smith (1): cmELF: Avoid divide by zero if there are no dynamic section entries From konstantin at podsvirov.pro Wed Dec 2 15:54:50 2015 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Wed, 02 Dec 2015 23:54:50 +0300 Subject: [cmake-developers] [ANNOUNCE] CMake 3.4.1 available for download In-Reply-To: References: Message-ID: <2288811449089690@web13j.yandex.ru> 02.12.2015, 22:55, "Robert Maynard" : > We are pleased to announce that CMake 3.4.1 is now available for download. > > Please use the latest release from our download page: > ??https://cmake.org/download/ > > Thanks for your support! Good job! Thank you! I could not miss this event. This is a good occasion to remind about the existence of CPack "IFW" generator :-) https://cmake.org/cmake/help/v3.4/module/CPackIFW.html Here is a fresh not official offline installers for CMake 3.4.1 on Windows: http://ifw.podsvirov.pro/cmake/files/v3.4/cmake-3.4.1-win32-x86.exe and http://ifw.podsvirov.pro/cmake/files/v3.4/cmake-3.4.1-win64-x64.exe But I want to assure you that they are honestly built me personally of the official code of branch 'release' recently :-) I'll be glad if somebody test these installers for themselves and to share their comments and suggestions. Good luck to everyone! -- Regards, Konstantin Podsvirov From Bartosz.Kosiorek at tomtom.com Wed Dec 2 16:45:09 2015 From: Bartosz.Kosiorek at tomtom.com (Bartosz Kosiorek) Date: Wed, 2 Dec 2015 21:45:09 +0000 Subject: [cmake-developers] [PATCH] Fix Resource directory structure for iOS Bundles (Framework and Application), update Tests and Help Message-ID: <1449092707348.20332@tomtom.com> Hello. Patch in attachment allows to place resources in main Bundle directory (iOS specification), instead to always place in Resource directory (OSX specification. See more: https://public.kitware.com/Bug/view.php?id=15848 ? I tested it intensively with different generators (Makefile, Ninja), and it works perfectly. I also extended existing Framework tests, to check Resource directory structure and Headers directory structure. All tests on my machine passed. Is it possible to apply this patch? We need this fix in CMake 3.5. Thanks in advance Bartosz -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-iOS-resource-directory-update-help-and-test-bug-.patch Type: application/octet-stream Size: 10347 bytes Desc: 0001-Fix-iOS-resource-directory-update-help-and-test-bug-.patch URL: From mantis at public.kitware.com Wed Dec 2 17:20:38 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 2 Dec 2015 17:20:38 -0500 Subject: [cmake-developers] [CMake 0015870]: "cmake -E copy" command do not display error if source is directory Message-ID: <7b7f7e5b2630d73fd13b7581275f166e@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15870 ====================================================================== Reported By: gang65 Assigned To: ====================================================================== Project: CMake Issue ID: 15870 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-12-02 17:20 EST Last Modified: 2015-12-02 17:20 EST ====================================================================== Summary: "cmake -E copy" command do not display error if source is directory Description: In current cmake implementation, by command: "cmake -E copy directory1 directory2" Do not copy anything and do not displays errors. Expected: cmake should display error message that directory "directory1" was not copied. It could be guarded by new Cmake policy Steps to Reproduce: mkdir directory1 mkdir directory2 cmake -E copy directory1 directory2 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-12-02 17:20 gang65 New Issue ====================================================================== From Bartosz.Kosiorek at tomtom.com Wed Dec 2 19:05:54 2015 From: Bartosz.Kosiorek at tomtom.com (Bartosz Kosiorek) Date: Thu, 3 Dec 2015 00:05:54 +0000 Subject: [cmake-developers] [PATCH] Extend copy and copy_if_different commands with support multiple files Message-ID: <1449101154444.76828@tomtom.com> Hi. This patch allows to use multiple files in commands "copy" and "copy_if_different". Input files could be merged with wildcards. For example: ./bin/cmake -E copy bin/* CMakeFiles/* file.tar dupajasia If wrong file path were provided as input then the error will be displayed, but rest of the files will be copied. For example: ./bin/cmake -E copy bin/* CMakeFiles/* wrong_file file.tar dupajasia/ Error copying file "wrong_file" to "dupajasia/". If multipile input files were provided, then destination must be directory. Example: ./bin/cmake -E copy bin/* CMakeFiles/* wrong_file file.tar dupajasia/ctest Error: Target (copy) "dupajasia/ctest" is not a directory. ./bin/cmake -E copy bin/* dupajasia/ctest? Error: Target (copy) "dupajasia/ctest?" is not a directory. If only one input file was provided, then destination could be either file or directory: ./bin/cmake -E copy file.tar dupajasia/ctest This path is starting point for fixing bug 15703: ?https://public.kitware.com/Bug/view.php?id=15703 Best Regards Bartosz -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Extend-copy-and-copy_if_different-command-with-suppo.patch Type: text/x-patch Size: 7483 bytes Desc: 0001-Extend-copy-and-copy_if_different-command-with-suppo.patch URL: From ruslan_baratov at yahoo.com Wed Dec 2 22:09:39 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Thu, 3 Dec 2015 10:09:39 +0700 Subject: [cmake-developers] Fw: Please comment on ios-universal topic In-Reply-To: <1449060271344.76735@tomtom.com> References: <565DAD1B.60301@googlemail.com> <1449054144180.13106@tomtom.com> <1449060271344.76735@tomtom.com> Message-ID: <565FB273.7070207@yahoo.com> On 02-Dec-15 19:44, Bartosz Kosiorek wrote: > Hi. > > Currently we already support similar target properties: > - INSTALL_NAME_DIR > - INSTALL_RPATH > - INSTALL_RPATH_USE_LINK_PATH > > It will be great to follow the same name convention. > > Because this new property is only applicable for INSTALL step, I would like to propose to rename property name to INSTALL_IOS_UNIVERSAL_LIBS. > > What do you think about that idea? It's hard for me to decide what is better because IOS_INSTALL_UNIVERSAL_LIBS just came from my mind and I've used it for a while already. So now it looks solid for no reason :) However first note: INSTALL_RPATH can be read as when we do INSTALL change RPATH to ... (any platform) ANDROID_API -//- when we are on ANDROID use next API ... WIN32_EXECUTABLE -//- when we are on WIN32 use bla-bla for EXECUTABLE OSX_ARCHITECTURES -//- when we are on OSX use ARCHITECTURES MACOSX_BUNDLE -//- when we are on MACOSX create BUNDLE So new property can be read as: IOS_INSTALL_UNIVERSAL_LIBS when we are on IOS do INSTALL_UNIVERSAL_LIBS INSTALL_IOS_UNIVERSAL_LIBS when we do INSTALL make IOS_UNIVERSAL_LIBS (does it mean that when we are on Linux we can install iOS libs? does it mean that when we are on OSX without iOS toolchain we can do iOS libs?) Second note is about future improvements of this feature, installing universal libs on OSX or installing universal frameworks, pattern _INSTALL_UNIVERSAL_: IOS_INSTALL_UNIVERSAL_LIBS IOS_INSTALL_UNIVERSAL_FRAMEWORKS OSX_INSTALL_UNIVERSAL_LIBS OSX_INSTALL_UNIVERSAL_FRAMEWORKS INSTALL_UNIVERSAL_LIBS # on both OSX and iOS INSTALL_UNIVERSAL_FRAMEWORKS # on both OSX and iOS IOS_INSTALL_UNIVERSAL # both libs and frameworks OSX_INSTALL_UNIVERSAL # both libs and frameworks INSTALL_UNIVERSAL # both libs and frameworks, both OSX and iOS ? Ruslo > > ________________________________________ > From: cmake-developers on behalf of Gregor Jasny via cmake-developers > Sent: Tuesday, December 1, 2015 3:22 PM > To: CMake Developers; Ruslan Baratov > Subject: [cmake-developers] Please comment on ios-universal topic > > Hello, > > During the last days I worked on the iOS Universal Install topic which > now would benefit from a review. Especially the core changes could need > a third pair of eyes: > > https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=8fb23b42cfc2fb7490e8645fff328add9c231713 > > I will now concentrate on adding more tests during the next days. > > Thank you, > Gregor > > -- > > 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 From konstantin at podsvirov.pro Thu Dec 3 02:24:45 2015 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Thu, 03 Dec 2015 10:24:45 +0300 Subject: [cmake-developers] [ANNOUNCE] CMake 3.4.1 available for download In-Reply-To: <2288811449089690@web13j.yandex.ru> References: <2288811449089690@web13j.yandex.ru> Message-ID: <1739831449127485@web22g.yandex.ru> Meet the fresh update online installers (CMake3.4.20151203): http://ifw.podsvirov.pro/cmake/cmake-master-win32-online.exe and http://ifw.podsvirov.pro/cmake/cmake-master-win64-online.exe If you have used them previously, then just update via "CMake Maintenance Tool". 02.12.2015, 23:55, "Konstantin Podsvirov" : > 02.12.2015, 22:55, "Robert Maynard" : >> ?We are pleased to announce that CMake 3.4.1 is now available for download. >> >> ?Please use the latest release from our download page: >> ???https://cmake.org/download/ >> >> ?Thanks for your support! > > Good job! Thank you! > > I could not miss this event. This is a good occasion to remind about > the existence of CPack "IFW" generator :-) > > https://cmake.org/cmake/help/v3.4/module/CPackIFW.html > > Here is a fresh not official offline installers for CMake 3.4.1 on Windows: > > http://ifw.podsvirov.pro/cmake/files/v3.4/cmake-3.4.1-win32-x86.exe > > and > > http://ifw.podsvirov.pro/cmake/files/v3.4/cmake-3.4.1-win64-x64.exe > > But I want to assure you that they are honestly built me personally of the official code of branch 'release' recently :-) > > I'll be glad if somebody test these installers for themselves and to share their comments and suggestions. > > Good luck to everyone! > > -- > Regards, > Konstantin Podsvirov > -- > > 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 Regards, Konstantin Podsvirov From Bartosz.Kosiorek at tomtom.com Thu Dec 3 02:57:44 2015 From: Bartosz.Kosiorek at tomtom.com (Bartosz Kosiorek) Date: Thu, 3 Dec 2015 07:57:44 +0000 Subject: [cmake-developers] Fw: Please comment on ios-universal topic In-Reply-To: <565FB273.7070207@yahoo.com> References: <565DAD1B.60301@googlemail.com> <1449054144180.13106@tomtom.com> <1449060271344.76735@tomtom.com>,<565FB273.7070207@yahoo.com> Message-ID: <1449129463970.39189@tomtom.com> Thanks Ruslan for feedback. I think that this new property should work also for FRAMEWORK and should support both OSX and iOS In that way it is already done for: - for SHARED library adding FRAMEWORK property produce correct Framework for iOS or OSX (for Cmake 3.5 the documentation was already updated), and standard library for other platforms - for MACOSX_BUNDLE (the name of property is very confusing). It will produce BUNDLE for OSX or iOS. - even standard SHARED library produce different results according to platform (.so file on Linux, .dll on Windows, .dylib on OSX) I strongly believe that this new CMake's property should follow this convention. Currently I'm working in project which must support multiple platforms (Linux, Windows, OSX, iOS, Android, QNX etc.). And I very like CMake for automagicaly adopting to platform/architecture/OS. Because "Universal Library" is generic name, which is applicable for all platforms (Fat library is used on Apple machines), I would like to propose following property name: INSTALL_UNIVERSAL_LIBRARY For now it will be applicable only on iOS (OS X?), but it could be extended to other platforms (Android). Of course all supported platforms should be noticed in documentation. What do you think about that idea: Adding one property which will adopt to platform on which is build? Best Regards Bartosz ________________________________________ From: Ruslan Baratov Sent: Thursday, December 3, 2015 4:09 AM To: Bartosz Kosiorek Cc: Gregor Jasny; cmake-developers at cmake.org Subject: Re: Fw: [cmake-developers] Please comment on ios-universal topic On 02-Dec-15 19:44, Bartosz Kosiorek wrote: > Hi. > > Currently we already support similar target properties: > - INSTALL_NAME_DIR > - INSTALL_RPATH > - INSTALL_RPATH_USE_LINK_PATH > > It will be great to follow the same name convention. > > Because this new property is only applicable for INSTALL step, I would like to propose to rename property name to INSTALL_IOS_UNIVERSAL_LIBS. > > What do you think about that idea? It's hard for me to decide what is better because IOS_INSTALL_UNIVERSAL_LIBS just came from my mind and I've used it for a while already. So now it looks solid for no reason :) However first note: INSTALL_RPATH can be read as when we do INSTALL change RPATH to ... (any platform) ANDROID_API -//- when we are on ANDROID use next API ... WIN32_EXECUTABLE -//- when we are on WIN32 use bla-bla for EXECUTABLE OSX_ARCHITECTURES -//- when we are on OSX use ARCHITECTURES MACOSX_BUNDLE -//- when we are on MACOSX create BUNDLE So new property can be read as: IOS_INSTALL_UNIVERSAL_LIBS when we are on IOS do INSTALL_UNIVERSAL_LIBS INSTALL_IOS_UNIVERSAL_LIBS when we do INSTALL make IOS_UNIVERSAL_LIBS (does it mean that when we are on Linux we can install iOS libs? does it mean that when we are on OSX without iOS toolchain we can do iOS libs?) Second note is about future improvements of this feature, installing universal libs on OSX or installing universal frameworks, pattern _INSTALL_UNIVERSAL_: IOS_INSTALL_UNIVERSAL_LIBS IOS_INSTALL_UNIVERSAL_FRAMEWORKS OSX_INSTALL_UNIVERSAL_LIBS OSX_INSTALL_UNIVERSAL_FRAMEWORKS INSTALL_UNIVERSAL_LIBS # on both OSX and iOS INSTALL_UNIVERSAL_FRAMEWORKS # on both OSX and iOS IOS_INSTALL_UNIVERSAL # both libs and frameworks OSX_INSTALL_UNIVERSAL # both libs and frameworks INSTALL_UNIVERSAL # both libs and frameworks, both OSX and iOS ? Ruslo > > ________________________________________ > From: cmake-developers on behalf of Gregor Jasny via cmake-developers > Sent: Tuesday, December 1, 2015 3:22 PM > To: CMake Developers; Ruslan Baratov > Subject: [cmake-developers] Please comment on ios-universal topic > > Hello, > > During the last days I worked on the iOS Universal Install topic which > now would benefit from a review. Especially the core changes could need > a third pair of eyes: > > https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=8fb23b42cfc2fb7490e8645fff328add9c231713 > > I will now concentrate on adding more tests during the next days. > > Thank you, > Gregor > > -- > > 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 From ruslan_baratov at yahoo.com Thu Dec 3 05:06:34 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Thu, 3 Dec 2015 17:06:34 +0700 Subject: [cmake-developers] Fw: Please comment on ios-universal topic In-Reply-To: <1449129463970.39189@tomtom.com> References: <565DAD1B.60301@googlemail.com> <1449054144180.13106@tomtom.com> <1449060271344.76735@tomtom.com> <565FB273.7070207@yahoo.com> <1449129463970.39189@tomtom.com> Message-ID: <5660142A.5070104@yahoo.com> On 03-Dec-15 14:57, Bartosz Kosiorek wrote: > Thanks Ruslan for feedback. > > I think that this new property should work also for FRAMEWORK and should support both OSX and iOS > In that way it is already done for: > - for SHARED library adding FRAMEWORK property produce correct Framework for iOS or OSX (for Cmake 3.5 the documentation was already updated), and standard library for other platforms > - for MACOSX_BUNDLE (the name of property is very confusing). It will produce BUNDLE for OSX or iOS. > - even standard SHARED library produce different results according to platform (.so file on Linux, .dll on Windows, .dylib on OSX) > > I strongly believe that this new CMake's property should follow this convention. > > Currently I'm working in project which must support multiple platforms (Linux, Windows, OSX, iOS, Android, QNX etc.). > And I very like CMake for automagicaly adopting to platform/architecture/OS. > > Because "Universal Library" is generic name, which is applicable for all platforms (Fat library is used on Apple machines), > I would like to propose following property name: > INSTALL_UNIVERSAL_LIBRARY > > For now it will be applicable only on iOS (OS X?), but it could be extended to other platforms (Android). > Of course all supported platforms should be noticed in documentation. > > What do you think about that idea: > Adding one property which will adopt to platform on which is build? Actually it make sense to me. We just need to add a note to the documentation that only Xcode + iOS libs supported for now and add new types/platforms in future. By the way does any other platform except Apple's OSX and iOS support fat libraries? You've mentioned Android (?) I've found this link about Linux: https://en.wikipedia.org/wiki/Fat_binary#FatELF:_Universal_Binaries_for_Linux (quote: `developer Ryan Gordon declared FatELF to be dead`) Ruslo > > > Best Regards > Bartosz > > ________________________________________ > From: Ruslan Baratov > Sent: Thursday, December 3, 2015 4:09 AM > To: Bartosz Kosiorek > Cc: Gregor Jasny; cmake-developers at cmake.org > Subject: Re: Fw: [cmake-developers] Please comment on ios-universal topic > > On 02-Dec-15 19:44, Bartosz Kosiorek wrote: >> Hi. >> >> Currently we already support similar target properties: >> - INSTALL_NAME_DIR >> - INSTALL_RPATH >> - INSTALL_RPATH_USE_LINK_PATH >> >> It will be great to follow the same name convention. >> >> Because this new property is only applicable for INSTALL step, I would like to propose to rename property name to INSTALL_IOS_UNIVERSAL_LIBS. >> >> What do you think about that idea? > It's hard for me to decide what is better because > IOS_INSTALL_UNIVERSAL_LIBS just came from my mind and I've used it for a > while already. So now it looks solid for no reason :) > > However first note: > INSTALL_RPATH can be read as when we do INSTALL change RPATH to ... > (any platform) > ANDROID_API -//- when we are on ANDROID use next API ... > WIN32_EXECUTABLE -//- when we are on WIN32 use bla-bla for EXECUTABLE > OSX_ARCHITECTURES -//- when we are on OSX use ARCHITECTURES > MACOSX_BUNDLE -//- when we are on MACOSX create BUNDLE > > So new property can be read as: > IOS_INSTALL_UNIVERSAL_LIBS when we are on IOS do INSTALL_UNIVERSAL_LIBS > INSTALL_IOS_UNIVERSAL_LIBS when we do INSTALL make IOS_UNIVERSAL_LIBS > (does it mean that when we are on Linux we can install iOS libs? does it > mean that when we are on OSX without iOS toolchain we can do iOS libs?) > > Second note is about future improvements of this feature, installing > universal libs on OSX or installing universal frameworks, pattern > _INSTALL_UNIVERSAL_: > > IOS_INSTALL_UNIVERSAL_LIBS > IOS_INSTALL_UNIVERSAL_FRAMEWORKS > > OSX_INSTALL_UNIVERSAL_LIBS > OSX_INSTALL_UNIVERSAL_FRAMEWORKS > > INSTALL_UNIVERSAL_LIBS # on both OSX and iOS > INSTALL_UNIVERSAL_FRAMEWORKS # on both OSX and iOS > > IOS_INSTALL_UNIVERSAL # both libs and frameworks > OSX_INSTALL_UNIVERSAL # both libs and frameworks > > INSTALL_UNIVERSAL # both libs and frameworks, both OSX and iOS > > ? > > Ruslo >> ________________________________________ >> From: cmake-developers on behalf of Gregor Jasny via cmake-developers >> Sent: Tuesday, December 1, 2015 3:22 PM >> To: CMake Developers; Ruslan Baratov >> Subject: [cmake-developers] Please comment on ios-universal topic >> >> Hello, >> >> During the last days I worked on the iOS Universal Install topic which >> now would benefit from a review. Especially the core changes could need >> a third pair of eyes: >> >> https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=8fb23b42cfc2fb7490e8645fff328add9c231713 >> >> I will now concentrate on adding more tests during the next days. >> >> Thank you, >> Gregor >> >> -- >> >> 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 From Bartosz.Kosiorek at tomtom.com Thu Dec 3 06:45:09 2015 From: Bartosz.Kosiorek at tomtom.com (Bartosz Kosiorek) Date: Thu, 3 Dec 2015 11:45:09 +0000 Subject: [cmake-developers] Fw: Please comment on ios-universal topic In-Reply-To: <5660142A.5070104@yahoo.com> References: <565DAD1B.60301@googlemail.com> <1449054144180.13106@tomtom.com> <1449060271344.76735@tomtom.com> <565FB273.7070207@yahoo.com> <1449129463970.39189@tomtom.com>,<5660142A.5070104@yahoo.com> Message-ID: <1449143109399.64147@tomtom.com> Hello Ruslan The Android supports both Universal Apk and Multi Apk. https://androidbycode.wordpress.com/2015/07/07/android-ndk-a-guide-to-deploying-apps-with-native-libraries/ http://developer.android.com/google/play/publishing/multiple-apks.html It is necessary for deploy applications which support both armv7 (32bit) and armv8 (64bit). There is also Intel's implementation of Android (x86) All supported architectures you could found at: http://developer.android.com/ndk/guides/abis.html It is possible to create universal library for Linux (FatElf), but it is not widely used: http://stackoverflow.com/questions/10167821/why-are-universal-binaries-fatelf-not-part-of-linux-kernel I don't know how it works with Universal Windows Platform: https://msdn.microsoft.com/en-us/library/windows/apps/dn894631.aspx https://msdn.microsoft.com/en-us/library/mt186162.aspx But I suspect that it will be similar. Best Regards Bartosz ________________________________________ From: Ruslan Baratov Sent: Thursday, December 3, 2015 11:06 AM To: Bartosz Kosiorek Cc: Gregor Jasny; cmake-developers at cmake.org Subject: Re: Fw: [cmake-developers] Please comment on ios-universal topic On 03-Dec-15 14:57, Bartosz Kosiorek wrote: > Thanks Ruslan for feedback. > > I think that this new property should work also for FRAMEWORK and should support both OSX and iOS > In that way it is already done for: > - for SHARED library adding FRAMEWORK property produce correct Framework for iOS or OSX (for Cmake 3.5 the documentation was already updated), and standard library for other platforms > - for MACOSX_BUNDLE (the name of property is very confusing). It will produce BUNDLE for OSX or iOS. > - even standard SHARED library produce different results according to platform (.so file on Linux, .dll on Windows, .dylib on OSX) > > I strongly believe that this new CMake's property should follow this convention. > > Currently I'm working in project which must support multiple platforms (Linux, Windows, OSX, iOS, Android, QNX etc.). > And I very like CMake for automagicaly adopting to platform/architecture/OS. > > Because "Universal Library" is generic name, which is applicable for all platforms (Fat library is used on Apple machines), > I would like to propose following property name: > INSTALL_UNIVERSAL_LIBRARY > > For now it will be applicable only on iOS (OS X?), but it could be extended to other platforms (Android). > Of course all supported platforms should be noticed in documentation. > > What do you think about that idea: > Adding one property which will adopt to platform on which is build? Actually it make sense to me. We just need to add a note to the documentation that only Xcode + iOS libs supported for now and add new types/platforms in future. By the way does any other platform except Apple's OSX and iOS support fat libraries? You've mentioned Android (?) I've found this link about Linux: https://en.wikipedia.org/wiki/Fat_binary#FatELF:_Universal_Binaries_for_Linux (quote: `developer Ryan Gordon declared FatELF to be dead`) Ruslo > > > Best Regards > Bartosz > > ________________________________________ > From: Ruslan Baratov > Sent: Thursday, December 3, 2015 4:09 AM > To: Bartosz Kosiorek > Cc: Gregor Jasny; cmake-developers at cmake.org > Subject: Re: Fw: [cmake-developers] Please comment on ios-universal topic > > On 02-Dec-15 19:44, Bartosz Kosiorek wrote: >> Hi. >> >> Currently we already support similar target properties: >> - INSTALL_NAME_DIR >> - INSTALL_RPATH >> - INSTALL_RPATH_USE_LINK_PATH >> >> It will be great to follow the same name convention. >> >> Because this new property is only applicable for INSTALL step, I would like to propose to rename property name to INSTALL_IOS_UNIVERSAL_LIBS. >> >> What do you think about that idea? > It's hard for me to decide what is better because > IOS_INSTALL_UNIVERSAL_LIBS just came from my mind and I've used it for a > while already. So now it looks solid for no reason :) > > However first note: > INSTALL_RPATH can be read as when we do INSTALL change RPATH to ... > (any platform) > ANDROID_API -//- when we are on ANDROID use next API ... > WIN32_EXECUTABLE -//- when we are on WIN32 use bla-bla for EXECUTABLE > OSX_ARCHITECTURES -//- when we are on OSX use ARCHITECTURES > MACOSX_BUNDLE -//- when we are on MACOSX create BUNDLE > > So new property can be read as: > IOS_INSTALL_UNIVERSAL_LIBS when we are on IOS do INSTALL_UNIVERSAL_LIBS > INSTALL_IOS_UNIVERSAL_LIBS when we do INSTALL make IOS_UNIVERSAL_LIBS > (does it mean that when we are on Linux we can install iOS libs? does it > mean that when we are on OSX without iOS toolchain we can do iOS libs?) > > Second note is about future improvements of this feature, installing > universal libs on OSX or installing universal frameworks, pattern > _INSTALL_UNIVERSAL_: > > IOS_INSTALL_UNIVERSAL_LIBS > IOS_INSTALL_UNIVERSAL_FRAMEWORKS > > OSX_INSTALL_UNIVERSAL_LIBS > OSX_INSTALL_UNIVERSAL_FRAMEWORKS > > INSTALL_UNIVERSAL_LIBS # on both OSX and iOS > INSTALL_UNIVERSAL_FRAMEWORKS # on both OSX and iOS > > IOS_INSTALL_UNIVERSAL # both libs and frameworks > OSX_INSTALL_UNIVERSAL # both libs and frameworks > > INSTALL_UNIVERSAL # both libs and frameworks, both OSX and iOS > > ? > > Ruslo >> ________________________________________ >> From: cmake-developers on behalf of Gregor Jasny via cmake-developers >> Sent: Tuesday, December 1, 2015 3:22 PM >> To: CMake Developers; Ruslan Baratov >> Subject: [cmake-developers] Please comment on ios-universal topic >> >> Hello, >> >> During the last days I worked on the iOS Universal Install topic which >> now would benefit from a review. Especially the core changes could need >> a third pair of eyes: >> >> https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=8fb23b42cfc2fb7490e8645fff328add9c231713 >> >> I will now concentrate on adding more tests during the next days. >> >> Thank you, >> Gregor >> >> -- >> >> 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 From marc.chevrier at sap.com Thu Dec 3 06:43:00 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Thu, 3 Dec 2015 11:43:00 +0000 Subject: [cmake-developers] [CMake][PATCH] Various Java support enhancements Message-ID: <3F6353ED-0B3F-4626-BD04-E8A0DC04F33B@sap.com> Hi, Attached are small patches enhancing Java support : 1. Fix some typo errors (introduced by myself :( 2. Enable to specify manifest file as relative path (same behaviour as java sources) 3. Add support for AIX/powerpc Java toolkits Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-fix-typo-errors.patch Type: application/octet-stream Size: 997 bytes Desc: 0001-fix-typo-errors.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-manifest-file-can-be-specified-as-relative-path.patch Type: application/octet-stream Size: 753 bytes Desc: 0002-manifest-file-can-be-specified-as-relative-path.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Add-support-of-AIX-java-sdk.patch Type: application/octet-stream Size: 1427 bytes Desc: 0003-Add-support-of-AIX-java-sdk.patch URL: From Bartosz.Kosiorek at tomtom.com Thu Dec 3 07:20:27 2015 From: Bartosz.Kosiorek at tomtom.com (Bartosz Kosiorek) Date: Thu, 3 Dec 2015 12:20:27 +0000 Subject: [cmake-developers] Fw: Please comment on ios-universal topic In-Reply-To: <1449143109399.64147@tomtom.com> References: <565DAD1B.60301@googlemail.com> <1449054144180.13106@tomtom.com> <1449060271344.76735@tomtom.com> <565FB273.7070207@yahoo.com> <1449129463970.39189@tomtom.com>, <5660142A.5070104@yahoo.com>, <1449143109399.64147@tomtom.com> Message-ID: <1449145227708.26735@tomtom.com> Hi again. I get through link: https://en.wikipedia.org/wiki/Fat_binary and I think it will be better to name this property: INSTALL_UNIVERSAL_BINARY Later such property name could be used also for Executables/Bundles etc. And the result for both Libraries and Executables will be the same. Best Regads Bartosz ________________________________________ From: Bartosz Kosiorek Sent: Thursday, December 3, 2015 12:45 PM To: Ruslan Baratov Cc: Gregor Jasny; cmake-developers at cmake.org Subject: Re: Fw: [cmake-developers] Please comment on ios-universal topic Hello Ruslan The Android supports both Universal Apk and Multi Apk. https://androidbycode.wordpress.com/2015/07/07/android-ndk-a-guide-to-deploying-apps-with-native-libraries/ http://developer.android.com/google/play/publishing/multiple-apks.html It is necessary for deploy applications which support both armv7 (32bit) and armv8 (64bit). There is also Intel's implementation of Android (x86) All supported architectures you could found at: http://developer.android.com/ndk/guides/abis.html It is possible to create universal library for Linux (FatElf), but it is not widely used: http://stackoverflow.com/questions/10167821/why-are-universal-binaries-fatelf-not-part-of-linux-kernel I don't know how it works with Universal Windows Platform: https://msdn.microsoft.com/en-us/library/windows/apps/dn894631.aspx https://msdn.microsoft.com/en-us/library/mt186162.aspx But I suspect that it will be similar. Best Regards Bartosz ________________________________________ From: Ruslan Baratov Sent: Thursday, December 3, 2015 11:06 AM To: Bartosz Kosiorek Cc: Gregor Jasny; cmake-developers at cmake.org Subject: Re: Fw: [cmake-developers] Please comment on ios-universal topic On 03-Dec-15 14:57, Bartosz Kosiorek wrote: > Thanks Ruslan for feedback. > > I think that this new property should work also for FRAMEWORK and should support both OSX and iOS > In that way it is already done for: > - for SHARED library adding FRAMEWORK property produce correct Framework for iOS or OSX (for Cmake 3.5 the documentation was already updated), and standard library for other platforms > - for MACOSX_BUNDLE (the name of property is very confusing). It will produce BUNDLE for OSX or iOS. > - even standard SHARED library produce different results according to platform (.so file on Linux, .dll on Windows, .dylib on OSX) > > I strongly believe that this new CMake's property should follow this convention. > > Currently I'm working in project which must support multiple platforms (Linux, Windows, OSX, iOS, Android, QNX etc.). > And I very like CMake for automagicaly adopting to platform/architecture/OS. > > Because "Universal Library" is generic name, which is applicable for all platforms (Fat library is used on Apple machines), > I would like to propose following property name: > INSTALL_UNIVERSAL_LIBRARY > > For now it will be applicable only on iOS (OS X?), but it could be extended to other platforms (Android). > Of course all supported platforms should be noticed in documentation. > > What do you think about that idea: > Adding one property which will adopt to platform on which is build? Actually it make sense to me. We just need to add a note to the documentation that only Xcode + iOS libs supported for now and add new types/platforms in future. By the way does any other platform except Apple's OSX and iOS support fat libraries? You've mentioned Android (?) I've found this link about Linux: https://en.wikipedia.org/wiki/Fat_binary#FatELF:_Universal_Binaries_for_Linux (quote: `developer Ryan Gordon declared FatELF to be dead`) Ruslo > > > Best Regards > Bartosz > > ________________________________________ > From: Ruslan Baratov > Sent: Thursday, December 3, 2015 4:09 AM > To: Bartosz Kosiorek > Cc: Gregor Jasny; cmake-developers at cmake.org > Subject: Re: Fw: [cmake-developers] Please comment on ios-universal topic > > On 02-Dec-15 19:44, Bartosz Kosiorek wrote: >> Hi. >> >> Currently we already support similar target properties: >> - INSTALL_NAME_DIR >> - INSTALL_RPATH >> - INSTALL_RPATH_USE_LINK_PATH >> >> It will be great to follow the same name convention. >> >> Because this new property is only applicable for INSTALL step, I would like to propose to rename property name to INSTALL_IOS_UNIVERSAL_LIBS. >> >> What do you think about that idea? > It's hard for me to decide what is better because > IOS_INSTALL_UNIVERSAL_LIBS just came from my mind and I've used it for a > while already. So now it looks solid for no reason :) > > However first note: > INSTALL_RPATH can be read as when we do INSTALL change RPATH to ... > (any platform) > ANDROID_API -//- when we are on ANDROID use next API ... > WIN32_EXECUTABLE -//- when we are on WIN32 use bla-bla for EXECUTABLE > OSX_ARCHITECTURES -//- when we are on OSX use ARCHITECTURES > MACOSX_BUNDLE -//- when we are on MACOSX create BUNDLE > > So new property can be read as: > IOS_INSTALL_UNIVERSAL_LIBS when we are on IOS do INSTALL_UNIVERSAL_LIBS > INSTALL_IOS_UNIVERSAL_LIBS when we do INSTALL make IOS_UNIVERSAL_LIBS > (does it mean that when we are on Linux we can install iOS libs? does it > mean that when we are on OSX without iOS toolchain we can do iOS libs?) > > Second note is about future improvements of this feature, installing > universal libs on OSX or installing universal frameworks, pattern > _INSTALL_UNIVERSAL_: > > IOS_INSTALL_UNIVERSAL_LIBS > IOS_INSTALL_UNIVERSAL_FRAMEWORKS > > OSX_INSTALL_UNIVERSAL_LIBS > OSX_INSTALL_UNIVERSAL_FRAMEWORKS > > INSTALL_UNIVERSAL_LIBS # on both OSX and iOS > INSTALL_UNIVERSAL_FRAMEWORKS # on both OSX and iOS > > IOS_INSTALL_UNIVERSAL # both libs and frameworks > OSX_INSTALL_UNIVERSAL # both libs and frameworks > > INSTALL_UNIVERSAL # both libs and frameworks, both OSX and iOS > > ? > > Ruslo >> ________________________________________ >> From: cmake-developers on behalf of Gregor Jasny via cmake-developers >> Sent: Tuesday, December 1, 2015 3:22 PM >> To: CMake Developers; Ruslan Baratov >> Subject: [cmake-developers] Please comment on ios-universal topic >> >> Hello, >> >> During the last days I worked on the iOS Universal Install topic which >> now would benefit from a review. Especially the core changes could need >> a third pair of eyes: >> >> https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=8fb23b42cfc2fb7490e8645fff328add9c231713 >> >> I will now concentrate on adding more tests during the next days. >> >> Thank you, >> Gregor >> >> -- >> >> 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 From brad.king at kitware.com Thu Dec 3 08:45:03 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 3 Dec 2015 08:45:03 -0500 Subject: [cmake-developers] [PATCH] Extend copy and copy_if_different commands with support multiple files In-Reply-To: <1449101154444.76828@tomtom.com> References: <1449101154444.76828@tomtom.com> Message-ID: <5660475F.4040604@kitware.com> On 12/02/2015 07:05 PM, Bartosz Kosiorek wrote: > This patch allows to use multiple files in commands "copy" and "copy_if_different". Good, thanks. Please also extend the Tests/RunCMake/CommandLine test to cover this these operations. Thanks, -Brad From brad.king at kitware.com Thu Dec 3 09:08:13 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 3 Dec 2015 09:08:13 -0500 Subject: [cmake-developers] [PATCH] Fix Resource directory structure for iOS Bundles (Framework and Application), update Tests and Help In-Reply-To: <1449092707348.20332@tomtom.com> References: <1449092707348.20332@tomtom.com> Message-ID: <56604CCD.70606@kitware.com> On 12/02/2015 04:45 PM, Bartosz Kosiorek wrote: > Patch in attachment allows to place resources in main Bundle directory > (iOS specification), instead to always place in Resource directory. > > https://public.kitware.com/Bug/view.php?id=15848 Thanks, applied: iOS: Fix framework resource directory layout (#15848) https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e76ee2c0 -Brad From brad.king at kitware.com Thu Dec 3 09:29:42 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 3 Dec 2015 09:29:42 -0500 Subject: [cmake-developers] [CMake][PATCH] Various Java support enhancements In-Reply-To: <3F6353ED-0B3F-4626-BD04-E8A0DC04F33B@sap.com> References: <3F6353ED-0B3F-4626-BD04-E8A0DC04F33B@sap.com> Message-ID: <566051D6.7030504@kitware.com> On 12/03/2015 06:43 AM, CHEVRIER, Marc wrote: > 1. Fix some typo errors (introduced by myself :( Good catch. Sorry I didn't notice that during review. Those typos clearly came from the component renaming we discussed. Applied: FindJava: Fix typos in IdlJ and JarSigner component implementation https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d8b251e2 I queued it for merge to 'release' for inclusion in 3.4.2. > 2. Enable to specify manifest file as relative path > (same behaviour as java sources) Applied: UseJava: Allow relative path to manifest file just as with other sources https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=56c11eee > 3. Add support for AIX/powerpc Java toolkits Applied: FindJNI: Add support for AIX java sdk https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6fc91ffb Thanks, -Brad From Bartosz.Kosiorek at tomtom.com Thu Dec 3 11:05:52 2015 From: Bartosz.Kosiorek at tomtom.com (Bartosz Kosiorek) Date: Thu, 3 Dec 2015 16:05:52 +0000 Subject: [cmake-developers] [PATCH] Extend copy and copy_if_different commands with support multiple files In-Reply-To: <5660475F.4040604@kitware.com> References: <1449101154444.76828@tomtom.com>,<5660475F.4040604@kitware.com> Message-ID: <1449158752870.21799@tomtom.com> Hi. I would like to create following tests for copy and copy_if_different commands: cmake -E copy test_copy_command_dir/file1.txt test_copy_command_dir/target_directory1 Result: success E_copy-one-source-directory-target-is-directory-result.txt E_copy-one-source-directory-target-is-directory-stderr.txt cmake -E copy test_copy_command_dir/directory1/file4.txt Result: error E_copy-one-source-file-result.txt E_copy-one-source-file-stderr.txt cmake -E copy test_copy_command_dir/file1.txt test_copy_command_dir/file2.txt test_copy_command_dir/file3.txt test_copy_command_dir/target_directory2 Result: Success E_copy-three-source-files-target-is-directory-result.txt E_copy-three-source-files-target-is-directory-stderr.txt cmake -E copy test_copy_command_dir/file1.txt test_copy_command_dir/file2.txt test_copy_command_dir/file3.txt test_copy_command_dir/target_directory1/file4.txt Result: Error E_copy-three-source-files-target-is-file-result.txt E_copy-three-source-files-target-is-file-stderr.txt cmake -E copy test_copy_command_dir/file1.txt not_existing_file.bad test_copy_command_dir/file2.txt test_copy_command_dir/target_directory3 Result: Error. The correct files are copied successfuly E_copy-two-good-and-one-bad-source-files-target-is-directory-result.txt E_copy-two-good-and-one-bad-source-files-target-is-directory-stderr.txt cmake -E copy test_copy_command_dir/*.txt test_copy_command_dir/target_directory4 Result: Success E_copy-wildcard-source-files-target-is-directory-result.txt E_copy-wildcard-source-files-target-is-directory-stderr.txt cmake -E copy test_copy_command_dir/* test_copy_command_dir/directory1/file4.txt Result: Error E_copy-wildcard-source-files-target-is-file-result.txt E_copy-wildcard-source-files-target-is-file-stderr.txt The resource directory will be: test_copy_command_dir ??? directory1 ??? ??? file4.txt ??? ??? file5.txt ??? directory2 ??? file1.txt ??? file2.txt ??? file3.txt ??? target_directory1 ??? target_directory2 ??? target_directory3 ??? target_directory4 What do you think about that? After every step I will need to clean it up . ________________________________________ From: cmake-developers on behalf of Brad King Sent: Thursday, December 3, 2015 2:45 PM To: cmake-developers at cmake.org Subject: Re: [cmake-developers] [PATCH] Extend copy and copy_if_different commands with support multiple files On 12/02/2015 07:05 PM, Bartosz Kosiorek wrote: > This patch allows to use multiple files in commands "copy" and "copy_if_different". Good, thanks. Please also extend the Tests/RunCMake/CommandLine test to cover this these operations. Thanks, -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 From brad.king at kitware.com Thu Dec 3 11:38:32 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 3 Dec 2015 11:38:32 -0500 Subject: [cmake-developers] [PATCH] Extend copy and copy_if_different commands with support multiple files In-Reply-To: <1449158752870.21799@tomtom.com> References: <1449101154444.76828@tomtom.com> <5660475F.4040604@kitware.com> <1449158752870.21799@tomtom.com> Message-ID: <56607008.6000008@kitware.com> On 12/03/2015 11:05 AM, Bartosz Kosiorek wrote: > After every step I will need to clean it up . If you add these as cases in the RunCMake.CommandLine test then each one can get its own directory and the RunCMake infrastructure will take care of cleaning it up for each run. -Brad From Bartosz.Kosiorek at tomtom.com Thu Dec 3 12:31:10 2015 From: Bartosz.Kosiorek at tomtom.com (Bartosz Kosiorek) Date: Thu, 3 Dec 2015 17:31:10 +0000 Subject: [cmake-developers] [PATCH] Extend copy and copy_if_different commands with support multiple files In-Reply-To: <56607008.6000008@kitware.com> References: <1449101154444.76828@tomtom.com> <5660475F.4040604@kitware.com> <1449158752870.21799@tomtom.com>,<56607008.6000008@kitware.com> Message-ID: <1449163870887.72096@tomtom.com> When I'm trying to run test with wildcard: run_cmake_command(E_copy-wildcard-source-files-target-is-directory ${CMAKE_COMMAND} -E copy ${RunCMake_copy_TEST_SOURCE_DIR}/directory1/* ${RunCMake_copy_TEST_BINARY_DIR}) I've got an error: Error copying file "/home/kosiorek/dev/perforce/cmake-dev/Tests/RunCMake/CommandLine/test_copy_command_dir/directory1/*" to "/home/kosiorek/dev/perforce/cmake-dev/builddir/Tests/RunCMake/CommandLine/test_copy_command_dir". but when I'm running such command locally it work perfectly: /home/kosiorek/dev/perforce/cmake-dev/builddir/bin/cmake -E copy /home/kosiorek/dev/perforce/cmake-dev/Tests/RunCMake/CommandLine/test_copy_command_dir/directory1/* /home/kosiorek/dev/perforce/cmake-dev/builddir/Tests/RunCMake/CommandLine/test_copy_command_dir What I'm doing wrong ? ________________________________________ From: Brad King Sent: Thursday, December 3, 2015 5:38 PM To: Bartosz Kosiorek Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] [PATCH] Extend copy and copy_if_different commands with support multiple files On 12/03/2015 11:05 AM, Bartosz Kosiorek wrote: > After every step I will need to clean it up . If you add these as cases in the RunCMake.CommandLine test then each one can get its own directory and the RunCMake infrastructure will take care of cleaning it up for each run. -Brad From brad.king at kitware.com Thu Dec 3 13:07:39 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 3 Dec 2015 13:07:39 -0500 Subject: [cmake-developers] [PATCH] Extend copy and copy_if_different commands with support multiple files In-Reply-To: <1449163870887.72096@tomtom.com> References: <1449101154444.76828@tomtom.com> <5660475F.4040604@kitware.com> <1449158752870.21799@tomtom.com> <56607008.6000008@kitware.com> <1449163870887.72096@tomtom.com> Message-ID: <566084EB.5080301@kitware.com> On 12/03/2015 12:31 PM, Bartosz Kosiorek wrote: > When I'm trying to run test with wildcard: > run_cmake_command(E_copy-wildcard-source-files-target-is-directory ${CMAKE_COMMAND} -E copy > ${RunCMake_copy_TEST_SOURCE_DIR}/directory1/* > ${RunCMake_copy_TEST_BINARY_DIR}) > > I've got an error: The command is not running through a shell in that case so there is no step that expands the wildcard. This feature is not about wildcard expansion, but about multiple inputs to the copy. They can be spelled out explicitly in the command invocation, or passed through a variable containing a list populated by file(GLOB). -Brad From Bartosz.Kosiorek at tomtom.com Thu Dec 3 15:56:02 2015 From: Bartosz.Kosiorek at tomtom.com (Bartosz Kosiorek) Date: Thu, 3 Dec 2015 20:56:02 +0000 Subject: [cmake-developers] [PATCH] Extend copy and copy_if_different commands with support multiple files In-Reply-To: <566084EB.5080301@kitware.com> References: <1449101154444.76828@tomtom.com> <5660475F.4040604@kitware.com> <1449158752870.21799@tomtom.com> <56607008.6000008@kitware.com> <1449163870887.72096@tomtom.com>,<566084EB.5080301@kitware.com> Message-ID: <1449176162367.69827@tomtom.com> Hello. Here is the patch with tests. ________________________________________ From: Brad King Sent: Thursday, December 3, 2015 7:07 PM To: Bartosz Kosiorek Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] [PATCH] Extend copy and copy_if_different commands with support multiple files On 12/03/2015 12:31 PM, Bartosz Kosiorek wrote: > When I'm trying to run test with wildcard: > run_cmake_command(E_copy-wildcard-source-files-target-is-directory ${CMAKE_COMMAND} -E copy > ${RunCMake_copy_TEST_SOURCE_DIR}/directory1/* > ${RunCMake_copy_TEST_BINARY_DIR}) > > I've got an error: The command is not running through a shell in that case so there is no step that expands the wildcard. This feature is not about wildcard expansion, but about multiple inputs to the copy. They can be spelled out explicitly in the command invocation, or passed through a variable containing a list populated by file(GLOB). -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Extend-copy-and-copy_if_different-command-with-suppo.patch Type: text/x-patch Size: 7487 bytes Desc: 0001-Extend-copy-and-copy_if_different-command-with-suppo.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-unit-tests-for-copy-and-copy_if_different-comman.patch Type: text/x-patch Size: 11951 bytes Desc: 0002-Add-unit-tests-for-copy-and-copy_if_different-comman.patch URL: From mantis at public.kitware.com Thu Dec 3 17:13:48 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 3 Dec 2015 17:13:48 -0500 Subject: [cmake-developers] [CMake 0015871]: Cmake may select incorrect default generator on windows host Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15871 ====================================================================== Reported By: Richard Lang Assigned To: ====================================================================== Project: CMake Issue ID: 15871 Category: CMake Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-12-03 17:13 EST Last Modified: 2015-12-03 17:13 EST ====================================================================== Summary: Cmake may select incorrect default generator on windows host Description: Looking at cmake::ActualConfigure() method in cmake.cxx (line 1265 or thereabouts), comment indicates that in absence of a specified generator cmake running on a native Windows host (not Cygwin) should generate for the newest Visual Studio installation found on the system, and fall back to generating a NMake make file if none found (which seems sensible), however as far as I can see the code is actually going to select the OLDEST VS install. Haven't run any test cases, this is solely from code inspection. Steps to Reproduce: Run Cmake without generator specified on Windows host with more than 1 version of visual Studio installed. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-12-03 17:13 Richard Lang New Issue ====================================================================== From michael.scott250 at gmail.com Thu Dec 3 17:56:27 2015 From: michael.scott250 at gmail.com (Michael Scott) Date: Thu, 3 Dec 2015 22:56:27 +0000 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: <565DBC8B.9070402@kitware.com> References: <565DBC8B.9070402@kitware.com> Message-ID: <5660C89B.4070004@gmail.com> > Thanks. Applied with minor tweaks and merged to 'next' for testing: That's great, thanks. Now that the patches are in, would you say it's better to work on adding a deprecated toggle option to the cmake-gui, or to work on adding support for upgrading warnings to errors? Cheers, Michael From rleigh at codelibre.net Thu Dec 3 19:11:21 2015 From: rleigh at codelibre.net (Roger Leigh) Date: Fri, 4 Dec 2015 00:11:21 +0000 Subject: [cmake-developers] [PATCH] FindTIFF: Add imported targets In-Reply-To: <6bef44c4fe63e6eca28c53d712d2c9b4.squirrel@g.mail.aa.net.uk> References: <6bef44c4fe63e6eca28c53d712d2c9b4.squirrel@g.mail.aa.net.uk> Message-ID: <5660DA29.3090109@codelibre.net> On 02/12/2015 17:31, rleigh at codelibre.net wrote: > - Add TIFF::TIFF imported target > - Document imported target > - Add testcase to test the standard variables and the imported > target > > Also: > > - Add TIFF_INCLUDE_DIRS to match common practice > - Update documentation generally, including documenting > TIFF_INCLUDE_DIRS I hope this is now staged correctly for review. I've pushed a tiff-imported-target topic branch and merged into next: amys% ssh git at cmake.org stage cmake merge -b next tiff-imported-target Fetching upstream next Merge topic 'tiff-imported-target' into next 09f36344 Help: Document addition of FindTIFF imported targets a237b26d FindTIFF: Add imported targets and update documentation Auto-merging Tests/CMakeLists.txt Pushing upstream next Kind regards, Roger From taylor at braun-jones.org Thu Dec 3 23:12:08 2015 From: taylor at braun-jones.org (Taylor Braun-Jones) Date: Thu, 3 Dec 2015 23:12:08 -0500 Subject: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation In-Reply-To: <05a801d112d6$9b2e2910$d18a7b30$@codenest.com> References: <05a801d112d6$9b2e2910$d18a7b30$@codenest.com> Message-ID: Perhaps the Paris Climate talks would be good inspiration for tackling this feature. How many pounds of CO2 are emitted each year due to needless header compilation CPU cycles? :-) On Fri, Oct 30, 2015 at 1:48 AM, James Johnston wrote: >> -----Original Message----- > >> From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] > >> On Behalf Of Daniel Pfeifer > >> Sent: Wednesday, October 28, 2015 08:57 > >> To: Taylor Braun-Jones > >> Cc: CMake Developers > >> Subject: Re: [cmake-developers] RFC: CMake precompiled header support > >> and custom compiler based implementation > >> > >> On Tue, Oct 27, 2015 at 3:53 AM, Taylor Braun-Jones >> jones.org> wrote: > >> > What's the status of this PCH feature? Does it need testers? More > >> > design input? I'd love to see this feature in a future CMake release. > >> > Willing to help. > >> > >> I haven't worked on it for quite some time as I currently don't have a > > project > >> which needs it. > >> But I agree that we should get it into CMake, even if it does not > >> support > > all > >> generators yet. > >> Support for additional generators can be added successively. > >> > >> I will rebase my branch to master on the weekend, ie port it to > >> cmGeneratorTarget. > >> Then you are free to help with review, testing, and additional generators. > >> > >> Which generators are the most important for you? > > > > I'd also love to see some progress on PCH support, though I haven't had much > time recently... I'd be quite happy to test however with the below compilers > and generators - all of which we would use PCH support with: > > > > Generators: > > > > * Ninja > > * Visual Studio 2008 (eventually 2015) > > * Although we're not currently using it, CMake would be pretty broken > without supporting: Unix Makefiles > > > > Compilers: > > > > * Visual C++ 2008 (eventually 2015): both Ninja and VS generators > > * Embarcadero bcc32 compiler: Ninja > > * GCC: Ninja > > > > Best regards, > > > > James Johnston > > > -- > > 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 From ruslan_baratov at yahoo.com Thu Dec 3 23:54:13 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Fri, 4 Dec 2015 11:54:13 +0700 Subject: [cmake-developers] Fw: Please comment on ios-universal topic In-Reply-To: <1449143109399.64147@tomtom.com> References: <565DAD1B.60301@googlemail.com> <1449054144180.13106@tomtom.com> <1449060271344.76735@tomtom.com> <565FB273.7070207@yahoo.com> <1449129463970.39189@tomtom.com> <5660142A.5070104@yahoo.com> <1449143109399.64147@tomtom.com> Message-ID: <56611C75.1010304@yahoo.com> On 03-Dec-15 18:45, Bartosz Kosiorek wrote: > Hello Ruslan > > The Android supports both Universal Apk and Multi Apk. > https://androidbycode.wordpress.com/2015/07/07/android-ndk-a-guide-to-deploying-apps-with-native-libraries/ > http://developer.android.com/google/play/publishing/multiple-apks.html > > It is necessary for deploy applications which support both armv7 (32bit) and armv8 (64bit). > There is also Intel's implementation of Android (x86) > All supported architectures you could found at: > http://developer.android.com/ndk/guides/abis.html > > It is possible to create universal library for Linux (FatElf), but it is not widely used: > http://stackoverflow.com/questions/10167821/why-are-universal-binaries-fatelf-not-part-of-linux-kernel > > I don't know how it works with Universal Windows Platform: > https://msdn.microsoft.com/en-us/library/windows/apps/dn894631.aspx > https://msdn.microsoft.com/en-us/library/mt186162.aspx > But I suspect that it will be similar. Thanks for the links. Will set aside some time to read them :) On 03-Dec-15 19:20, Bartosz Kosiorek wrote: > Hi again. > > I get through link: > https://en.wikipedia.org/wiki/Fat_binary > > and I think it will be better to name this property: > INSTALL_UNIVERSAL_BINARY > > Later such property name could be used also for Executables/Bundles etc. > And the result for both Libraries and Executables will be the same. Yes, if this option is planned to be extended for iOS/OSX bundles too so it make sense to combine *_LIBRARY and *_BUNDLE into one *_BINARY. Sounds good for me. Ruslo From daniel at pfeifer-mail.de Fri Dec 4 02:27:49 2015 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Fri, 4 Dec 2015 08:27:49 +0100 Subject: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation In-Reply-To: References: <05a801d112d6$9b2e2910$d18a7b30$@codenest.com> Message-ID: My working branch is here: https://github.com/purpleKarrot/CMake/commits/pch Feel free to comment, evaluate, contribute. I am nut fully decided regarding these two questions: - Do we want to support different pch per CONFIG? I think no, but I might be wrong. - Do we want to support different pch per LANGUAGE? I first thought yes, but I am no longer certain about that. On Fri, Dec 4, 2015 at 5:12 AM, Taylor Braun-Jones wrote: > Perhaps the Paris Climate talks would be good inspiration for tackling > this feature. How many pounds of CO2 are emitted each year due to > needless header compilation CPU cycles? :-) > > On Fri, Oct 30, 2015 at 1:48 AM, James Johnston > wrote: >>> -----Original Message----- >> >>> From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] >> >>> On Behalf Of Daniel Pfeifer >> >>> Sent: Wednesday, October 28, 2015 08:57 >> >>> To: Taylor Braun-Jones >> >>> Cc: CMake Developers >> >>> Subject: Re: [cmake-developers] RFC: CMake precompiled header support >> >>> and custom compiler based implementation >> >>> >> >>> On Tue, Oct 27, 2015 at 3:53 AM, Taylor Braun-Jones > >>> jones.org> wrote: >> >>> > What's the status of this PCH feature? Does it need testers? More >> >>> > design input? I'd love to see this feature in a future CMake release. >> >>> > Willing to help. >> >>> >> >>> I haven't worked on it for quite some time as I currently don't have a >> >> project >> >>> which needs it. >> >>> But I agree that we should get it into CMake, even if it does not >> >>> support >> >> all >> >>> generators yet. >> >>> Support for additional generators can be added successively. >> >>> >> >>> I will rebase my branch to master on the weekend, ie port it to >> >>> cmGeneratorTarget. >> >>> Then you are free to help with review, testing, and additional generators. >> >>> >> >>> Which generators are the most important for you? >> >> >> >> I'd also love to see some progress on PCH support, though I haven't had much >> time recently... I'd be quite happy to test however with the below compilers >> and generators - all of which we would use PCH support with: >> >> >> >> Generators: >> >> >> >> * Ninja >> >> * Visual Studio 2008 (eventually 2015) >> >> * Although we're not currently using it, CMake would be pretty broken >> without supporting: Unix Makefiles >> >> >> >> Compilers: >> >> >> >> * Visual C++ 2008 (eventually 2015): both Ninja and VS generators >> >> * Embarcadero bcc32 compiler: Ninja >> >> * GCC: Ninja >> >> >> >> Best regards, >> >> >> >> James Johnston >> >> >> -- >> >> 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 From brad.king at kitware.com Fri Dec 4 08:27:37 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 4 Dec 2015 08:27:37 -0500 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: <5660C89B.4070004@gmail.com> References: <565DBC8B.9070402@kitware.com> <5660C89B.4070004@gmail.com> Message-ID: <566194C9.70405@kitware.com> On 12/03/2015 05:56 PM, Michael Scott wrote: >> Thanks. Applied with minor tweaks and merged to 'next' for testing: > > That's great, thanks. Now that the patches are in, would you say it's > better to work on adding a deprecated toggle option to the cmake-gui, or > to work on adding support for upgrading warnings to errors? Let's start with the toggle because that will make cmake-gui able to set the option just like the command line. Note that as part of integrating your changes I changed the CMAKE_WARN_DEPRECATED cache entry to INTERNAL instead of BOOL so it won't show up in the cmake-gui. Therefore a dedicated switch would be useful. Thanks, -Brad From DLRdave at aol.com Fri Dec 4 08:42:07 2015 From: DLRdave at aol.com (David Cole) Date: Fri, 4 Dec 2015 08:42:07 -0500 Subject: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation In-Reply-To: References: <05a801d112d6$9b2e2910$d18a7b30$@codenest.com> Message-ID: With Visual Studio, you definitely **need** separate pch for each CONFIG. Every pch is going to include headers which have Debug/Release differences in them, and it is not safe to mix and match compiler output from separate configs together. D On Friday, December 4, 2015, Daniel Pfeifer wrote: > My working branch is here: > https://github.com/purpleKarrot/CMake/commits/pch > > Feel free to comment, evaluate, contribute. > > I am nut fully decided regarding these two questions: > - Do we want to support different pch per CONFIG? I think no, but I > might be wrong. > - Do we want to support different pch per LANGUAGE? I first thought > yes, but I am no longer certain about that. > > On Fri, Dec 4, 2015 at 5:12 AM, Taylor Braun-Jones > > wrote: > > Perhaps the Paris Climate talks would be good inspiration for tackling > > this feature. How many pounds of CO2 are emitted each year due to > > needless header compilation CPU cycles? :-) > > > > On Fri, Oct 30, 2015 at 1:48 AM, James Johnston > > > wrote: > >>> -----Original Message----- > >> > >>> From: cmake-developers [mailto:cmake-developers-bounces at cmake.org > ] > >> > >>> On Behalf Of Daniel Pfeifer > >> > >>> Sent: Wednesday, October 28, 2015 08:57 > >> > >>> To: Taylor Braun-Jones > >> > >>> Cc: CMake Developers > >> > >>> Subject: Re: [cmake-developers] RFC: CMake precompiled header support > >> > >>> and custom compiler based implementation > >> > >>> > >> > >>> On Tue, Oct 27, 2015 at 3:53 AM, Taylor Braun-Jones >> > >>> jones.org> wrote: > >> > >>> > What's the status of this PCH feature? Does it need testers? More > >> > >>> > design input? I'd love to see this feature in a future CMake release. > >> > >>> > Willing to help. > >> > >>> > >> > >>> I haven't worked on it for quite some time as I currently don't have a > >> > >> project > >> > >>> which needs it. > >> > >>> But I agree that we should get it into CMake, even if it does not > >> > >>> support > >> > >> all > >> > >>> generators yet. > >> > >>> Support for additional generators can be added successively. > >> > >>> > >> > >>> I will rebase my branch to master on the weekend, ie port it to > >> > >>> cmGeneratorTarget. > >> > >>> Then you are free to help with review, testing, and additional > generators. > >> > >>> > >> > >>> Which generators are the most important for you? > >> > >> > >> > >> I'd also love to see some progress on PCH support, though I haven't had > much > >> time recently... I'd be quite happy to test however with the below > compilers > >> and generators - all of which we would use PCH support with: > >> > >> > >> > >> Generators: > >> > >> > >> > >> * Ninja > >> > >> * Visual Studio 2008 (eventually 2015) > >> > >> * Although we're not currently using it, CMake would be pretty broken > >> without supporting: Unix Makefiles > >> > >> > >> > >> Compilers: > >> > >> > >> > >> * Visual C++ 2008 (eventually 2015): both Ninja and VS generators > >> > >> * Embarcadero bcc32 compiler: Ninja > >> > >> * GCC: Ninja > >> > >> > >> > >> Best regards, > >> > >> > >> > >> James Johnston > >> > >> > >> -- > >> > >> 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 > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gang65 at poczta.onet.pl Fri Dec 4 09:18:37 2015 From: gang65 at poczta.onet.pl (Bartosz Kosiorek) Date: Fri, 4 Dec 2015 15:18:37 +0100 Subject: [cmake-developers] [PATCH] Extend copy and copy_if_different commands with support multiple files In-Reply-To: <1449176162367.69827@tomtom.com> References: <1449101154444.76828@tomtom.com> <5660475F.4040604@kitware.com> <1449158752870.21799@tomtom.com> <56607008.6000008@kitware.com> <1449163870887.72096@tomtom.com> <566084EB.5080301@kitware.com> <1449176162367.69827@tomtom.com> Message-ID: Good Morning Finally I manage to add wildcard support. I have taken SimpleGlob.h library from: https://github.com/brofield/simpleopt It is multiplatform, which supports all UNIX glob functions/flags and implementead as single header library. I tested it on Linux and it is working perfectly for me. SimpleGlob.h library you need to copy into Source/SimpleGlob.h path. Please let me know what do you think about that solution. If it is ok for you, I will continue testing on WIndows and OS X platforms. Best Regards Bartosz 2015-12-03 21:56 GMT+01:00 Bartosz Kosiorek : > Hello. > > Here is the patch with tests. > ________________________________________ > From: Brad King > Sent: Thursday, December 3, 2015 7:07 PM > To: Bartosz Kosiorek > Cc: cmake-developers at cmake.org > Subject: Re: [cmake-developers] [PATCH] Extend copy and copy_if_different > commands with support multiple files > > On 12/03/2015 12:31 PM, Bartosz Kosiorek wrote: > > When I'm trying to run test with wildcard: > > run_cmake_command(E_copy-wildcard-source-files-target-is-directory > ${CMAKE_COMMAND} -E copy > > ${RunCMake_copy_TEST_SOURCE_DIR}/directory1/* > > ${RunCMake_copy_TEST_BINARY_DIR}) > > > > I've got an error: > > The command is not running through a shell in that case so there is > no step that expands the wildcard. This feature is not about wildcard > expansion, but about multiple inputs to the copy. They can be > spelled out explicitly in the command invocation, or passed through > a variable containing a list populated by file(GLOB). > > -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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Extend-copy-and-copy_if_different-command-with-suppo.patch Type: text/x-patch Size: 7487 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-unit-tests-for-copy-and-copy_if_different-comman.patch Type: text/x-patch Size: 11951 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Add-support-for-glob-by-using-SimpleGlob.h-library.patch Type: text/x-patch Size: 10619 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SimpleGlob.h Type: text/x-chdr Size: 30984 bytes Desc: not available URL: From michael.scott250 at gmail.com Fri Dec 4 10:05:12 2015 From: michael.scott250 at gmail.com (Michael Scott) Date: Fri, 4 Dec 2015 15:05:12 +0000 Subject: [cmake-developers] Add command line options for deprecation message control Message-ID: <5661ABA8.4000001@gmail.com> > Let's start with the toggle because that will make cmake-gui able > to set the option just like the command line. Sounds good, that's what I was thinking as well. > Also I'm not sure what to do about persistence of the option check > boxes in cmake-gui when selecting a different build tree. As a user > I may expect those options to be loaded from the current cache in each > build tree I select. The build tree is selected by changing the source directory setting in the GUI right? So it should get the state of the checkboxes based on the cache whenever this changes. Adding in one toggle would be fine, but I imagine that when we come to adding support for upgrading warnings to errors, the additional two checkboxes would be a bit much. I was thinking of perhaps instead having just one entry in the options menu, which opens up a sub-window which contains the group of message related options. Cheers, Michale From brad.king at kitware.com Fri Dec 4 10:34:10 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 4 Dec 2015 10:34:10 -0500 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: <5661ABA8.4000001@gmail.com> References: <5661ABA8.4000001@gmail.com> Message-ID: <5661B272.6050107@kitware.com> On 12/04/2015 10:05 AM, Michael Scott wrote: > The build tree is selected by changing the source directory setting in > the GUI right? Actually when one choose a build tree it will locate the corresponding source tree automatically if both exist. Selecting the source tree may be followed by creating a new build tree so that direction does not happen automatically IIRC. > Adding in one toggle would be fine, but I imagine that when we come to > adding support for upgrading warnings to errors, the additional two > checkboxes would be a bit much. I was thinking of perhaps instead having > just one entry in the options menu, which opens up a sub-window which > contains the group of message related options. Yes. Please move the -Wdev options there too. Actually since it is a property of the build tree selected and not of the overall session, perhaps the button for these settings should not be in the menu but in the dialog box somewhere below. Thanks, -Brad P.S. Your mailer broke the thread again. From brad.king at kitware.com Fri Dec 4 10:35:07 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 4 Dec 2015 10:35:07 -0500 Subject: [cmake-developers] [PATCH] Extend copy and copy_if_different commands with support multiple files In-Reply-To: References: <1449101154444.76828@tomtom.com> <5660475F.4040604@kitware.com> <1449158752870.21799@tomtom.com> <56607008.6000008@kitware.com> <1449163870887.72096@tomtom.com> <566084EB.5080301@kitware.com> <1449176162367.69827@tomtom.com> Message-ID: <5661B2AB.30907@kitware.com> On 12/04/2015 09:18 AM, Bartosz Kosiorek wrote: > Finally I manage to add wildcard support. > I have taken SimpleGlob.h library from: > https://github.com/brofield/simpleopt We don't want to do wildcard expansion in CMake commands. We want to leave it up to the shell to expand wildcards on the command line, or have explicit file(GLOB) commands in CMake script code. I've applied the patches from the previous post, with a slightly different breakdown and some fixes to the test: cmake: Improve '-E' help message formatting https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0be5020b cmake: Teach -E copy[_if_different] to support multiple files (#15703) https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=384ae551 Thanks, -Brad From brad.king at kitware.com Fri Dec 4 10:38:49 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 4 Dec 2015 10:38:49 -0500 Subject: [cmake-developers] [PATCH] FindTIFF: Add imported targets In-Reply-To: <5660DA29.3090109@codelibre.net> References: <6bef44c4fe63e6eca28c53d712d2c9b4.squirrel@g.mail.aa.net.uk> <5660DA29.3090109@codelibre.net> Message-ID: <5661B389.4050307@kitware.com> On 12/03/2015 07:11 PM, Roger Leigh wrote: > I hope this is now staged correctly for review. I've pushed a > tiff-imported-target topic branch and merged into next: Yes, thanks. I've just updated a nightly build client to enable the test for this. -Brad From michael.scott250 at gmail.com Fri Dec 4 10:52:17 2015 From: michael.scott250 at gmail.com (Michael Scott) Date: Fri, 4 Dec 2015 15:52:17 +0000 Subject: [cmake-developers] Add command line options for deprecation message control Message-ID: <5661B6B1.5090901@gmail.com> > Actually when one choose a build tree it will locate the corresponding > source tree automatically if both exist. Selecting the source tree > may be followed by creating a new build tree so that direction does > not happen automatically IIRC. Okay, I'm not too familiar with the GUI, how do you choose a build tree? So that I can look at where I can hook in the message cache detection. > Your mailer broke the thread again. Sorry, this one shouldn't break the thread. Cheers, Michael From brad.king at kitware.com Fri Dec 4 11:12:48 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 4 Dec 2015 11:12:48 -0500 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: <5661B6B1.5090901@gmail.com> References: <5661B6B1.5090901@gmail.com> Message-ID: <5661BB80.8070007@kitware.com> On 12/04/2015 10:52 AM, Michael Scott wrote: >> Actually when one choose a build tree it will locate the corresponding >> source tree automatically if both exist. Selecting the source tree >> may be followed by creating a new build tree so that direction does >> not happen automatically IIRC. > Okay, I'm not too familiar with the GUI, how do you choose a build tree? > So that I can look at where I can hook in the message cache detection. There are two directory fields: "Where is the source code:" "Where to build the binaries:" The latter is the build tree selection. >> Your mailer broke the thread again. > Sorry, this one shouldn't break the thread. It did. -Brad From gang65 at poczta.onet.pl Fri Dec 4 11:15:05 2015 From: gang65 at poczta.onet.pl (Bartosz Kosiorek) Date: Fri, 4 Dec 2015 17:15:05 +0100 Subject: [cmake-developers] [PATCH] Extend copy and copy_if_different commands with support multiple files In-Reply-To: <5661B2AB.30907@kitware.com> References: <1449101154444.76828@tomtom.com> <5660475F.4040604@kitware.com> <1449158752870.21799@tomtom.com> <56607008.6000008@kitware.com> <1449163870887.72096@tomtom.com> <566084EB.5080301@kitware.com> <1449176162367.69827@tomtom.com> <5661B2AB.30907@kitware.com> Message-ID: Thanks Brad. Unfortunately we cannot use file(GLOB), because it is executed during generate step, and we would like to copy files which is created during Build step. Currently for filtering these files, we are using "cmake -E tar" to filter these files (so it packing and upacking). I think it is awful solution, but I cannot find better. What would you propose in that case? Is it possible to introduce "cmake -E list" command with wildcard support, to be able to filter files/directories, during Build step? The we couid use it to "cmake -E copy" command Best Regards Bartosz 2015-12-04 16:35 GMT+01:00 Brad King : > On 12/04/2015 09:18 AM, Bartosz Kosiorek wrote: > > Finally I manage to add wildcard support. > > I have taken SimpleGlob.h library from: > > https://github.com/brofield/simpleopt > > We don't want to do wildcard expansion in CMake commands. We want to leave > it up to the shell to expand wildcards on the command line, or have > explicit > file(GLOB) commands in CMake script code. > > I've applied the patches from the previous post, with a slightly > different breakdown and some fixes to the test: > > cmake: Improve '-E' help message formatting > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0be5020b > > cmake: Teach -E copy[_if_different] to support multiple files (#15703) > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=384ae551 > > Thanks, > -Brad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at pfeifer-mail.de Fri Dec 4 12:26:12 2015 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Fri, 4 Dec 2015 18:26:12 +0100 Subject: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation In-Reply-To: References: <05a801d112d6$9b2e2910$d18a7b30$@codenest.com> Message-ID: > On Friday, December 4, 2015, Daniel Pfeifer wrote: >> >> My working branch is here: >> https://github.com/purpleKarrot/CMake/commits/pch >> >> Feel free to comment, evaluate, contribute. >> >> I am nut fully decided regarding these two questions: >> - Do we want to support different pch per CONFIG? I think no, but I >> might be wrong. >> - Do we want to support different pch per LANGUAGE? I first thought >> yes, but I am no longer certain about that. On Fri, Dec 4, 2015 at 2:42 PM, David Cole wrote: > With Visual Studio, you definitely **need** separate pch for each CONFIG. > Every pch is going to include headers which have Debug/Release differences > in them, and it is not safe to mix and match compiler output from separate > configs together. Maybe we are confusing two things here. Visual Studio compiles a pch-binary for each configuration. That pch-binary is probably incompatible with other configurations. In my current implementation, the header file that is used to compile the pch-binary is generated by CMake, using information provided by the user. This approach is very powerful, as it supports usage requirements. See here for an example: You can see here: https://github.com/purpleKarrot/CMake/blob/e441eac5b16fd245e6aa014867d43d53c18b6d4d/Tests/PrecompileHeaders/CMakeLists.txt My question actually boils down to whether CMake should (a) generate a header file for each configuration/language, or (b) generate a **single** header file which is then precompiled for all configurations/languages. Both approaches are possible, because we can use #ifdef __cplusplus etc. More importantly: Do we want the user to (c) tell CMake about different headers-to-be-precompiled per config/language so CMake can write the appropriate #ifdefs into the generated file, or (d) put #ifdefs into the provided file so that CMake can #include it in the generated file without any additional logic? Again both approaches are technically possible. It is not about what we **need**, but what we **want**. And there, I am undecided. From brad.king at kitware.com Fri Dec 4 13:21:37 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 4 Dec 2015 13:21:37 -0500 Subject: [cmake-developers] [PATCH] Extend copy and copy_if_different commands with support multiple files In-Reply-To: References: <1449101154444.76828@tomtom.com> <5660475F.4040604@kitware.com> <1449158752870.21799@tomtom.com> <56607008.6000008@kitware.com> <1449163870887.72096@tomtom.com> <566084EB.5080301@kitware.com> <1449176162367.69827@tomtom.com> <5661B2AB.30907@kitware.com> Message-ID: <5661D9B1.3000502@kitware.com> On 12/04/2015 11:15 AM, Bartosz Kosiorek wrote: > we cannot use file(GLOB), because it is executed during generate step, > and we would like to copy files which is created during Build step. The custom commands always execute inside a shell that can do glob expansion. Alternatively, use a "cmake -P myscript.cmake" to script the copy with e.g. file(COPY) optionally with file(GLOB). Generally we don't recommend globbing because it can accidentally get stale files. If you are creating files during the build step, don't you know what files are being created? -Brad From DLRdave at aol.com Fri Dec 4 15:19:52 2015 From: DLRdave at aol.com (David Cole) Date: Fri, 4 Dec 2015 15:19:52 -0500 Subject: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation In-Reply-To: References: <05a801d112d6$9b2e2910$d18a7b30$@codenest.com> Message-ID: Right, I was talking about the pch-binary. Why would CMake even need to generate a header file for pre-compiled headers? Why not just allow the user to say which of his header files should be the one to use for precompiled headers? I have a project I work on which is a VS-only non-CMake based project, where we name the pch input header files as "${libraryName}PCH.h" and anything we want included in the pch-binary we can just add to that file. Personally, I would prefer to have a manually edited file as the input to precompiled header so I can add whatever I want in there. What would be in the contents of the generated header? How do you know how much or how little is reasonable to put in there? Seems like a per-library / per-project sort of decision. D On Fri, Dec 4, 2015 at 12:26 PM, Daniel Pfeifer wrote: >> On Friday, December 4, 2015, Daniel Pfeifer wrote: >>> >>> My working branch is here: >>> https://github.com/purpleKarrot/CMake/commits/pch >>> >>> Feel free to comment, evaluate, contribute. >>> >>> I am nut fully decided regarding these two questions: >>> - Do we want to support different pch per CONFIG? I think no, but I >>> might be wrong. >>> - Do we want to support different pch per LANGUAGE? I first thought >>> yes, but I am no longer certain about that. > > On Fri, Dec 4, 2015 at 2:42 PM, David Cole wrote: >> With Visual Studio, you definitely **need** separate pch for each CONFIG. >> Every pch is going to include headers which have Debug/Release differences >> in them, and it is not safe to mix and match compiler output from separate >> configs together. > > Maybe we are confusing two things here. > > Visual Studio compiles a pch-binary for each configuration. That > pch-binary is probably incompatible with other configurations. > In my current implementation, the header file that is used to compile > the pch-binary is generated by CMake, using information provided by > the user. > > This approach is very powerful, as it supports usage requirements. See > here for an example: > You can see here: > https://github.com/purpleKarrot/CMake/blob/e441eac5b16fd245e6aa014867d43d53c18b6d4d/Tests/PrecompileHeaders/CMakeLists.txt > > My question actually boils down to whether CMake should > (a) generate a header file for each configuration/language, or > (b) generate a **single** header file which is then precompiled for > all configurations/languages. > > Both approaches are possible, because we can use #ifdef __cplusplus etc. > > More importantly: Do we want the user to > (c) tell CMake about different headers-to-be-precompiled per > config/language so CMake can write the appropriate #ifdefs into the > generated file, or > (d) put #ifdefs into the provided file so that CMake can #include it > in the generated file without any additional logic? > > Again both approaches are technically possible. It is not about what > we **need**, but what we **want**. And there, I am undecided. From daniel at pfeifer-mail.de Fri Dec 4 17:28:13 2015 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Fri, 4 Dec 2015 23:28:13 +0100 Subject: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation In-Reply-To: References: <05a801d112d6$9b2e2910$d18a7b30$@codenest.com> Message-ID: On Fri, Dec 4, 2015 at 9:19 PM, David Cole wrote: > Right, I was talking about the pch-binary. > > Why would CMake even need to generate a header file for pre-compiled > headers? Why not just allow the user to say which of his header files > should be the one to use for precompiled headers? Generating a header file is necessary for two reasons: 1. In GCC, the compiled pch-binary has to be located in the same directory as the pch-source header. For out-of-source-builds, we certainly do not want to clutter the source directory, so we need a header file inside the binary directory. We could create a copy (fragile), a symlink (not portable), or a forward-#include (preferred). 2. There can be only one pch per target. See below. > I have a project I work on which is a VS-only non-CMake based project, > where we name the pch input header files as "${libraryName}PCH.h" and > anything we want included in the pch-binary we can just add to that > file. > > Personally, I would prefer to have a manually edited file as the input > to precompiled header so I can add whatever I want in there. That is perfectly reasonable. This is also the reason why I think the config/language specific differences should **not** be handled by CMake, but by the user. > What would be in the contents of the generated header? How do you know > how much or how little is reasonable to put in there? Seems like a > per-library / per-project sort of decision. If you look at the example I referred to, there is a library `foo` with a pch `foo.h` as a usage requirement. There is also an interface library `bar` with a pch `bar.h` as a usage requirement. Then there is an executable `foobar` which links against both `foo` and bar`. So the generated pch-source for the `foobar` target will contain: ---- /* This file is generated by CMake */ #include #include ---- Making sense? From DLRdave at aol.com Fri Dec 4 17:32:38 2015 From: DLRdave at aol.com (David Cole) Date: Fri, 4 Dec 2015 17:32:38 -0500 Subject: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation In-Reply-To: References: <05a801d112d6$9b2e2910$d18a7b30$@codenest.com> Message-ID: Makes sense. Can I inject my own "#include " into the generated stream, or otherwise inject something into it? Specifically, for me, I want to include some, but not ALL VTK headers for a VTK-based project. Thanks for working on this. Let me know if you want me to be a Visual Studio tester for you. D On Fri, Dec 4, 2015 at 5:28 PM, Daniel Pfeifer wrote: > On Fri, Dec 4, 2015 at 9:19 PM, David Cole wrote: >> Right, I was talking about the pch-binary. >> >> Why would CMake even need to generate a header file for pre-compiled >> headers? Why not just allow the user to say which of his header files >> should be the one to use for precompiled headers? > > Generating a header file is necessary for two reasons: > > 1. In GCC, the compiled pch-binary has to be located in the same > directory as the pch-source header. For out-of-source-builds, we > certainly do not want to clutter the source directory, so we need a > header file inside the binary directory. We could create a copy > (fragile), a symlink (not portable), or a forward-#include > (preferred). > > 2. There can be only one pch per target. See below. > >> I have a project I work on which is a VS-only non-CMake based project, >> where we name the pch input header files as "${libraryName}PCH.h" and >> anything we want included in the pch-binary we can just add to that >> file. >> >> Personally, I would prefer to have a manually edited file as the input >> to precompiled header so I can add whatever I want in there. > > That is perfectly reasonable. This is also the reason why I think the > config/language specific differences should **not** be handled by > CMake, but by the user. > >> What would be in the contents of the generated header? How do you know >> how much or how little is reasonable to put in there? Seems like a >> per-library / per-project sort of decision. > > If you look at the example I referred to, there is a library `foo` > with a pch `foo.h` as a usage requirement. There is also an interface > library `bar` with a pch `bar.h` as a usage requirement. Then there is > an executable `foobar` which links against both `foo` and bar`. So the > generated pch-source for the `foobar` target will contain: > > ---- > /* This file is generated by CMake */ > #include > #include > ---- > > Making sense? From daniel at pfeifer-mail.de Fri Dec 4 17:50:14 2015 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Fri, 4 Dec 2015 23:50:14 +0100 Subject: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation In-Reply-To: References: <05a801d112d6$9b2e2910$d18a7b30$@codenest.com> Message-ID: On Fri, Dec 4, 2015 at 11:32 PM, David Cole wrote: > Makes sense. > > Can I inject my own "#include " into > the generated stream, or otherwise inject something into it? You should be able to do: target_include_directories(your_target PUBLIC public PRIVATE private ) target_precompile_headers(your_target PUBLIC public_header1.h public_header2.h PRIVATE private_header1.h private_header2.h ) Does that answer your question? Do you think this could solve your use-case? > Specifically, for me, I want to include some, but not ALL VTK headers > for a VTK-based project. I don't see a problem for that. > Thanks for working on this. You are welcome. :-) > Let me know if you want me to be a Visual Studio tester for you. Yes, please. My main working environment is Linux. I appreciate any feedback from different platforms. From taylor at braun-jones.org Sat Dec 5 02:21:38 2015 From: taylor at braun-jones.org (Taylor Braun-Jones) Date: Sat, 5 Dec 2015 02:21:38 -0500 Subject: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation In-Reply-To: References: <05a801d112d6$9b2e2910$d18a7b30$@codenest.com> Message-ID: Thanks Daniel! I've just started playing with your pch branch. I like the implementation approach. It looks like precompiled headers for an INTERFACE IMPORTED target are not supported. Is that right? `cmake --help target_precompile_headers` doesn't work. I'll come back with more questions/comments as I continue to play with this pch branch. On Fri, Dec 4, 2015 at 5:50 PM, Daniel Pfeifer wrote: > On Fri, Dec 4, 2015 at 11:32 PM, David Cole wrote: > > Makes sense. > > > > Can I inject my own "#include " into > > the generated stream, or otherwise inject something into it? > > You should be able to do: > > target_include_directories(your_target > PUBLIC public > PRIVATE private > ) > target_precompile_headers(your_target > PUBLIC > public_header1.h > public_header2.h > PRIVATE > private_header1.h > private_header2.h > ) > > Does that answer your question? Do you think this could solve your > use-case? > > > Specifically, for me, I want to include some, but not ALL VTK headers > > for a VTK-based project. > > I don't see a problem for that. > > > Thanks for working on this. > > You are welcome. :-) > > > Let me know if you want me to be a Visual Studio tester for you. > > Yes, please. My main working environment is Linux. I appreciate any > feedback from different platforms. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Sat Dec 5 07:39:06 2015 From: DLRdave at aol.com (David Cole) Date: Sat, 5 Dec 2015 07:39:06 -0500 Subject: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation In-Reply-To: References: <05a801d112d6$9b2e2910$d18a7b30$@codenest.com> Message-ID: Yes, that looks like it should work. I'll pull your branch and give it a try sometime in the coming week. Thanks, David On Friday, December 4, 2015, Daniel Pfeifer wrote: > On Fri, Dec 4, 2015 at 11:32 PM, David Cole > wrote: > > Makes sense. > > > > Can I inject my own "#include " into > > the generated stream, or otherwise inject something into it? > > You should be able to do: > > target_include_directories(your_target > PUBLIC public > PRIVATE private > ) > target_precompile_headers(your_target > PUBLIC > public_header1.h > public_header2.h > PRIVATE > private_header1.h > private_header2.h > ) > > Does that answer your question? Do you think this could solve your > use-case? > > > Specifically, for me, I want to include some, but not ALL VTK headers > > for a VTK-based project. > > I don't see a problem for that. > > > Thanks for working on this. > > You are welcome. :-) > > > Let me know if you want me to be a Visual Studio tester for you. > > Yes, please. My main working environment is Linux. I appreciate any > feedback from different platforms. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.scott250 at gmail.com Sun Dec 6 08:13:25 2015 From: michael.scott250 at gmail.com (Michael Scott) Date: Sun, 6 Dec 2015 13:13:25 +0000 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: <5661BB80.8070007@kitware.com> References: <5661BB80.8070007@kitware.com> Message-ID: <56643475.5020403@gmail.com> Hi Brad, Here are a couple of patches for adding in support for controlling the suppression of deprecated warning messages, in the cmake-gui. Let me know if there's any issues with the changes. The first patch adds a new dialog window to control the suppression of developer and deprecated warning messages, the old single checkbox in the options menu is then replaced by this dialog. The dialog window uses the get/set suppression methods in the cmake class, which is based on the state of the cache, so I believe this should fulfil the intention that the options are loaded from the current state of the cache. The second patch just removes some duplicate code for setting the cache variables for the suppression of warning messages. Cheers, Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Warning-messages-options-in-cmake-gui.patch Type: text/x-diff Size: 16932 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Remove-duplicated-warning-message-control-code.patch Type: text/x-diff Size: 5582 bytes Desc: not available URL: From Bartosz.Kosiorek at tomtom.com Sun Dec 6 14:40:32 2015 From: Bartosz.Kosiorek at tomtom.com (Bartosz Kosiorek) Date: Sun, 6 Dec 2015 19:40:32 +0000 Subject: [cmake-developers] [PATCH] Add support for multiple parameters in cmake -E copy_directory command Message-ID: <1449430832061.76295@tomtom.com> Hello. I following patch I have added support for multiple source directories into copy_directory command. Comments are welcomed. Best Regards Bartosz -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-support-for-multiple-directory-for-copy_director.patch Type: text/x-patch Size: 9492 bytes Desc: 0001-Add-support-for-multiple-directory-for-copy_director.patch URL: From mantis at public.kitware.com Sun Dec 6 23:39:31 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 6 Dec 2015 21:39:31 -0700 Subject: [cmake-developers] [CMake 0015872]: Programs with Fortran entry point (but calls into C) don't link correctly using Intel or PGI compilers Message-ID: <83036adfce3842ed9f19eb0faaf9270f@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15872 ====================================================================== Reported By: Ben Matthews Assigned To: ====================================================================== Project: CMake Issue ID: 15872 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-12-06 21:39 MST Last Modified: 2015-12-06 21:39 MST ====================================================================== Summary: Programs with Fortran entry point (but calls into C) don't link correctly using Intel or PGI compilers Description: CMake always seems to link mixed language programs using the C++ compiler. Intel and PGI link libcrt, which wants to have a main(). Programs with a Fortran entry point typically won't have main(). Setting the linker_language property doesn't seem to make a difference. Using the GNU compilers, CMake still uses the C++ compiler, but it gets the libraries right and everything works as expected. Steps to Reproduce: git clone https://github.com/matthb2/cmake_f90_entry_bug.git cd cmake_f90_entry_bug mkdir build cd build CC=icc CXX=icpc FC=ifort cmake ../ make #### make Scanning dependencies of target testprog [ 50%] Building Fortran object CMakeFiles/testprog.dir/test.f90.o [100%] Linking CXX executable testprog /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' CMakeFiles/testprog.dir/build.make:94: recipe for target 'testprog' failed make[2]: *** [testprog] Error 1 CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/testprog.dir/all' failed make[1]: *** [CMakeFiles/testprog.dir/all] Error 2 Makefile:83: recipe for target 'all' failed make: *** [all] Error 2 Additional Information: Note that the example code is a bit of a simplified/contrived example. It will work fine if you remove the HAS_CXX property, but real cases also incorporate C/C++ modules and require that libc/libstdc++ be present. icc -V Intel(R) C Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.0.0.079 Build 20120731 Copyright (C) 1985-2012 Intel Corporation. All rights reserved. FOR NON-COMMERCIAL USE ONLY ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-12-06 21:39 Ben Matthews New Issue ====================================================================== From mantis at public.kitware.com Mon Dec 7 04:16:33 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 7 Dec 2015 04:16:33 -0500 Subject: [cmake-developers] [CMake 0015873]: CMake hangs indefinitely after executing other tools (e.g., gmake, getconf, file) Message-ID: <0e2c3a1475e9724b36ab4fef5446004f@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15873 ====================================================================== Reported By: Ralf Mitschke Assigned To: ====================================================================== Project: CMake Issue ID: 15873 Category: CMake Reproducibility: always Severity: block Priority: high Status: new ====================================================================== Date Submitted: 2015-12-07 04:16 EST Last Modified: 2015-12-07 04:16 EST ====================================================================== Summary: CMake hangs indefinitely after executing other tools (e.g., gmake, getconf, file) Description: CMake is used in a virtual machine environment and started from Jenkins for large scale build automation of C++ based projects (so not only a single project). The error mostly occurs in the compiler detection phase. The spawned gmake or getconf processes CMake calls are reported as zombie processes in the OS. The cmake process then hangs indefinitely in on a select statement to a UNIX pipe it needs for inter-process communication (a stack trace is posted as additional information). The issue was even observed earlier in the build, where CMake was executing the process "file", possibly to read the CMakeLists.txt or another input file. The frequency of the occurrence varies from machine to machine. But overall, it happens reliably in 1 of 500 runs. I suspect it is a timing issue and outside of automation not often found. As a workaround, I created a patched version of the file Source/kwsys/ProcessUNIX.c There was some code to completely remove the pipe select mechanism and revert to polling the pipes. By switching the following definition to false we got around the problem: # define KWSYSPE_USE_SELECT 0 But CMake seems to get slower when not using selects. Steps to Reproduce: - Create a simple C++ project - Run a batch script to start the build 1000 times. Additional Information: Stack trace where CMake hangs in pipe select statement: https://public.kitware.com/Bug/view.php?id=0 0x00007fab1410ea43 in __select_nocancel () from /lib64/libc.so.6 https://public.kitware.com/Bug/view.php?id=1 0x00000000007eb662 in cmsysProcess_WaitForData () https://public.kitware.com/Bug/view.php?id=2 0x00000000005c91ac in cmSystemTools::RunSingleCommand(std::vector > const&, std::string*, std::string*, int*, char const*, cmSystemTools::OutputOption, double) () https://public.kitware.com/Bug/view.php?id=3 0x000000000053c9f3 in cmGlobalGenerator::Build(std::string const&, std::string const&, std::string const&, std::string const&, std::string&, std::string const&, std::string const&, bool, bool, bool, double, cmSystemTools::OutputOption, std::vector > const&) () https://public.kitware.com/Bug/view.php?id=4 0x000000000053d093 in cmGlobalGenerator::TryCompile(std::string const&, std::string const&, std::string const&, std::string const&, bool, std::string&, cmMakefile*) () https://public.kitware.com/Bug/view.php?id=5 0x00000000005745bc in cmMakefile::TryCompile(std::string const&, std::string const&, std::string const&, std::string const&, bool, std::vector > const*, std::string&) () https://public.kitware.com/Bug/view.php?id=6 0x0000000000676745 in cmCoreTryCompile::TryCompileCode(std::vector > const&) () https://public.kitware.com/Bug/view.php?id=7 0x0000000000688453 in cmTryCompileCommand::InitialPass(std::vector > const&, cmExecutionStatus&) () https://public.kitware.com/Bug/view.php?id=8 0x0000000000584374 in cmMakefile::ExecuteCommand(cmListFileFunction const&, cmExecutionStatus&) () https://public.kitware.com/Bug/view.php?id=9 0x00000000006ac560 in cmIfFunctionBlocker::IsFunctionBlocked(cmListFileFunction const&, cmMakefile&, cmExecutionStatus&) () https://public.kitware.com/Bug/view.php?id=10 0x00000000005841b1 in cmMakefile::ExecuteCommand(cmListFileFunction const&, cmExecutionStatus&) () https://public.kitware.com/Bug/view.php?id=11 0x000000000065065f in cmFunctionHelperCommand::InvokeInitialPass(std::vector > const&, cmExecutionStatus&) () https://public.kitware.com/Bug/view.php?id=12 0x00000000005845cd in cmMakefile::ExecuteCommand(cmListFileFunction const&, cmExecutionStatus&) () https://public.kitware.com/Bug/view.php?id=13 0x00000000006ac560 in cmIfFunctionBlocker::IsFunctionBlocked(cmListFileFunction const&, cmMakefile&, cmExecutionStatus&) () https://public.kitware.com/Bug/view.php?id=14 0x00000000005841b1 in cmMakefile::ExecuteCommand(cmListFileFunction const&, cmExecutionStatus&) () https://public.kitware.com/Bug/view.php?id=15 0x00000000005848cc in cmMakefile::ReadListFileInternal(char const*, bool, bool) () https://public.kitware.com/Bug/view.php?id=16 0x0000000000585c6d in cmMakefile::ReadListFile(char const*, bool, bool) () https://public.kitware.com/Bug/view.php?id=17 0x0000000000586614 in cmMakefile::ReadListFile(char const*) () https://public.kitware.com/Bug/view.php?id=18 0x0000000000542e3c in cmGlobalGenerator::EnableLanguage(std::vector > const&, cmMakefile*, bool) () https://public.kitware.com/Bug/view.php?id=19 0x0000000000768d9d in cmGlobalUnixMakefileGenerator3::EnableLanguage(std::vector > const&, cmMakefile*, bool) () https://public.kitware.com/Bug/view.php?id=20 0x0000000000577313 in cmMakefile::EnableLanguage(std::vector > const&, bool) () https://public.kitware.com/Bug/view.php?id=21 0x00000000006a6ab7 in cmProjectCommand::InitialPass(std::vector > const&, cmExecutionStatus&) () https://public.kitware.com/Bug/view.php?id=22 0x0000000000584374 in cmMakefile::ExecuteCommand(cmListFileFunction const&, cmExecutionStatus&) () https://public.kitware.com/Bug/view.php?id=23 0x00000000005848cc in cmMakefile::ReadListFileInternal(char const*, bool, bool) () https://public.kitware.com/Bug/view.php?id=24 0x0000000000585c6d in cmMakefile::ReadListFile(char const*, bool, bool) () https://public.kitware.com/Bug/view.php?id=25 0x0000000000586428 in cmMakefile::ProcessBuildsystemFile(char const*) () https://public.kitware.com/Bug/view.php?id=26 0x000000000055f9fd in cmLocalGenerator::Configure() () https://public.kitware.com/Bug/view.php?id=27 0x0000000000795ad6 in cmLocalUnixMakefileGenerator3::Configure() () https://public.kitware.com/Bug/view.php?id=28 0x000000000054b0dc in cmGlobalGenerator::Configure() () https://public.kitware.com/Bug/view.php?id=29 0x0000000000768fbc in cmGlobalUnixMakefileGenerator3::Configure() () https://public.kitware.com/Bug/view.php?id=30 0x0000000000600a07 in cmake::ActualConfigure() () https://public.kitware.com/Bug/view.php?id=31 0x0000000000605523 in cmake::Configure() () https://public.kitware.com/Bug/view.php?id=32 0x000000000060946c in cmake::Run(std::vector > const&, bool) () https://public.kitware.com/Bug/view.php?id=33 0x000000000050eb76 in do_cmake(int, char const* const*) () https://public.kitware.com/Bug/view.php?id=34 0x00000000005103ee in main () ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-12-07 04:16 Ralf Mitschke New Issue ====================================================================== From brad.king at kitware.com Mon Dec 7 11:45:46 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 7 Dec 2015 11:45:46 -0500 Subject: [cmake-developers] [PATCH] Add support for multiple parameters in cmake -E copy_directory command In-Reply-To: <1449430832061.76295@tomtom.com> References: <1449430832061.76295@tomtom.com> Message-ID: <5665B7BA.5060204@kitware.com> On 12/06/2015 02:40 PM, Bartosz Kosiorek wrote: > added support for multiple source directories into copy_directory Thanks. Applied with minor tweaks: cmake: Refine -E chdir documentation https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0903812b cmake: Refine -E copy_if_different implementation indentation https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=93cc80ae cmake: Refine -E copy[_if_different] documentation https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=98be140f cmake: Teach -E copy_directory to support multiple input directories https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bc35087d -Brad From brad.king at kitware.com Mon Dec 7 11:48:25 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 7 Dec 2015 11:48:25 -0500 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: <56643475.5020403@gmail.com> References: <5661BB80.8070007@kitware.com> <56643475.5020403@gmail.com> Message-ID: <5665B859.3050807@kitware.com> On 12/06/2015 08:13 AM, Michael Scott wrote: > Here are a couple of patches for adding in support for controlling the > suppression of deprecated warning messages, in the cmake-gui. Nice, thanks. I noticed one glitch. I built against Qt 5.5.1 on Linux and the option dialog seems to truncate the labels. See attached image for a screenshot. -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: dialog.png Type: image/png Size: 4094 bytes Desc: not available URL: From michael.scott250 at gmail.com Mon Dec 7 13:51:33 2015 From: michael.scott250 at gmail.com (Michael Scott) Date: Mon, 7 Dec 2015 18:51:33 +0000 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: <5665B859.3050807@kitware.com> References: <5665B859.3050807@kitware.com> Message-ID: <5665D535.2070702@gmail.com> > I noticed one glitch. I built against Qt 5.5.1 on Linux and the > option dialog seems to truncate the labels. I think I've fixed it, by using vertical layouts rather than form layouts and setting the size policy to expanding for the widgets, if that doesn't fix I'll need to look into QT in more depth as I've not got much experience with it. Which Linux distro did you notice it in, looks like gnome3? Patches for the fix are attached. Cheers, Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Warning-messages-options-in-cmake-gui.patch Type: text/x-diff Size: 17106 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Remove-duplicated-warning-message-control-code.patch Type: text/x-diff Size: 5582 bytes Desc: not available URL: From domen.vrankar at gmail.com Mon Dec 7 14:24:57 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Mon, 7 Dec 2015 20:24:57 +0100 Subject: [cmake-developers] [CPackRPM] Configure RPM package group and name per component In-Reply-To: References: <5648DDC4.2080901@fortiss.org> Message-ID: 2015-11-17 9:18 GMT+01:00 Domen Vrankar : > 2015-11-15 20:32 GMT+01:00 Markus Rickert : >> Hi, >> >> similar to the previous patch for CPackDeb, the attached patch adds >> component-specific settings for group and name of an RPM package. >> >> CPACK_RPM__PACKAGE_GROUP allows setting the group of the >> component with the main libraries to "Development/Libraries", while >> "Documentation" can be used for the component with the actual documentation. >> >> CPACK_RPM__PACKAGE_NAME can set the package name (not the >> filename) of a component, e.g., "foo" for libraries (instead of >> "foo-libraries") and "foo-devel" for headers. > > I'll try to review it today. Sorry for this delay... Applied patch with minor change: https://cmake.org/gitweb?p=cmake.git;a=commit;h=c926efa Thanks, Domen From a.huebl at hzdr.de Mon Dec 7 19:53:24 2015 From: a.huebl at hzdr.de (Huebl, Axel) Date: Tue, 8 Dec 2015 01:53:24 +0100 Subject: [cmake-developers] Static Bootstrap: CCMake & GPM In-Reply-To: <566629C0.60400@hzdr.de> References: <566629C0.60400@hzdr.de> Message-ID: <56662A04.4090406@hzdr.de> Forgot to say: I did build the latest version 3.4.1 On 08.12.2015 01:52, Huebl, Axel wrote: > Hi, > > I did build a static version of CMake today successfully via > > LDFLAGS="-static-libstdc++ -static-libgcc -static" \ > CFLAGS="-fPIC" \ > CXXFLAGS="-fPIC" \ > ./bootstrap > > make -j > make install > > (the -fPIC could also be superfluous, I just realized later that I need > to build my gcc via -fPIC, too.) > > My problem: I found that in the last step of linking ccmake against a > static (pre-compiled, ubuntu 12.04) ncurses library leads to linker > errors such as: > > /usr/lib/x86_64-linux-gnu/libncurses.a(lib_mouse.o): In function > `_nc_mouse_event': > (.text+0x61e): undefined reference to `Gpm_GetEvent' > /usr/lib/x86_64-linux-gnu/libncurses.a(lib_mouse.o): In function > `enable_gpm_mouse': > (.text+0x78c): undefined reference to `Gpm_Close' > /usr/lib/x86_64-linux-gnu/libncurses.a(lib_mouse.o): In function > `enable_gpm_mouse': > (.text+0x7ce): undefined reference to `Gpm_Open' > /usr/lib/x86_64-linux-gnu/libncurses.a(lib_mouse.o): In function > `enable_gpm_mouse': > (.text+0x7df): undefined reference to `Gpm_Close' > /usr/lib/x86_64-linux-gnu/libncurses.a(lib_mouse.o): In function > `initialize_mousetype': > (.text+0x935): undefined reference to `gpm_fd' > /usr/lib/x86_64-linux-gnu/libncurses.a(lib_mouse.o): In function > `mouse_activate': > (.text+0xb67): undefined reference to `gpm_fd' > > > I then used the make VERBOSE=1 output to simply add the static libgmp.a > via -lgpm in the end of the line to finish the install. > > Is it possible that the GPM dependency is missing in the ccmake install > scripts? I tried to find the lines in > > https://github.com/Kitware/CMake/blob/master/Source/CursesDialog/CMakeLists.txt > > but could not find a place to add it. > > > Cheers, > Axel > -- Axel Huebl Phone +49 351 260 3582 https://www.hzdr.de/crp Computational Radiation Physics Laser Particle Acceleration Division Helmholtz-Zentrum Dresden - Rossendorf e.V. Bautzner Landstrasse 400, 01328 Dresden POB 510119, D-01314 Dresden Vorstand: Prof. Dr.Dr.h.c. R. Sauerbrey Prof. Dr.Dr.h.c. P. Joehnk VR 1693 beim Amtsgericht Dresden -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5119 bytes Desc: S/MIME Cryptographic Signature URL: From a.huebl at hzdr.de Mon Dec 7 19:52:16 2015 From: a.huebl at hzdr.de (Huebl, Axel) Date: Tue, 8 Dec 2015 01:52:16 +0100 Subject: [cmake-developers] Static Bootstrap: CCMake & GPM Message-ID: <566629C0.60400@hzdr.de> Hi, I did build a static version of CMake today successfully via LDFLAGS="-static-libstdc++ -static-libgcc -static" \ CFLAGS="-fPIC" \ CXXFLAGS="-fPIC" \ ./bootstrap make -j make install (the -fPIC could also be superfluous, I just realized later that I need to build my gcc via -fPIC, too.) My problem: I found that in the last step of linking ccmake against a static (pre-compiled, ubuntu 12.04) ncurses library leads to linker errors such as: /usr/lib/x86_64-linux-gnu/libncurses.a(lib_mouse.o): In function `_nc_mouse_event': (.text+0x61e): undefined reference to `Gpm_GetEvent' /usr/lib/x86_64-linux-gnu/libncurses.a(lib_mouse.o): In function `enable_gpm_mouse': (.text+0x78c): undefined reference to `Gpm_Close' /usr/lib/x86_64-linux-gnu/libncurses.a(lib_mouse.o): In function `enable_gpm_mouse': (.text+0x7ce): undefined reference to `Gpm_Open' /usr/lib/x86_64-linux-gnu/libncurses.a(lib_mouse.o): In function `enable_gpm_mouse': (.text+0x7df): undefined reference to `Gpm_Close' /usr/lib/x86_64-linux-gnu/libncurses.a(lib_mouse.o): In function `initialize_mousetype': (.text+0x935): undefined reference to `gpm_fd' /usr/lib/x86_64-linux-gnu/libncurses.a(lib_mouse.o): In function `mouse_activate': (.text+0xb67): undefined reference to `gpm_fd' I then used the make VERBOSE=1 output to simply add the static libgmp.a via -lgpm in the end of the line to finish the install. Is it possible that the GPM dependency is missing in the ccmake install scripts? I tried to find the lines in https://github.com/Kitware/CMake/blob/master/Source/CursesDialog/CMakeLists.txt but could not find a place to add it. Cheers, Axel -- Axel Huebl Phone +49 351 260 3582 https://www.hzdr.de/crp Computational Radiation Physics Laser Particle Acceleration Division Helmholtz-Zentrum Dresden - Rossendorf e.V. Bautzner Landstrasse 400, 01328 Dresden POB 510119, D-01314 Dresden Vorstand: Prof. Dr.Dr.h.c. R. Sauerbrey Prof. Dr.Dr.h.c. P. Joehnk VR 1693 beim Amtsgericht Dresden -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5119 bytes Desc: S/MIME Cryptographic Signature URL: From gjasny at googlemail.com Tue Dec 8 03:33:23 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Tue, 8 Dec 2015 09:33:23 +0100 Subject: [cmake-developers] Static Bootstrap: CCMake & GPM In-Reply-To: <56662A04.4090406@hzdr.de> References: <566629C0.60400@hzdr.de> <56662A04.4090406@hzdr.de> Message-ID: <566695D3.1020609@googlemail.com> Hello Axel, On 08/12/15 01:53, Huebl, Axel wrote: >> My problem: I found that in the last step of linking ccmake against a >> static (pre-compiled, ubuntu 12.04) ncurses library leads to linker >> errors such as: >> >> /usr/lib/x86_64-linux-gnu/libncurses.a(lib_mouse.o): In function >> `_nc_mouse_event': Could you please post the content of /usr/lib/x86_64-linux-gnu/pkgconfig/ncurses.pc ? Thanks, Gregor From a.huebl at hzdr.de Tue Dec 8 03:59:20 2015 From: a.huebl at hzdr.de (Huebl, Axel) Date: Tue, 8 Dec 2015 09:59:20 +0100 Subject: [cmake-developers] Static Bootstrap: CCMake & GPM In-Reply-To: <566695D3.1020609@googlemail.com> References: <566629C0.60400@hzdr.de> <56662A04.4090406@hzdr.de> <566695D3.1020609@googlemail.com> Message-ID: <56669BE8.7040804@hzdr.de> Hello Gregor, On 08.12.2015 09:33, Gregor Jasny wrote: > Hello Axel, > > On 08/12/15 01:53, Huebl, Axel wrote: >>> My problem: I found that in the last step of linking ccmake against a >>> static (pre-compiled, ubuntu 12.04) ncurses library leads to linker >>> errors such as: >>> >>> /usr/lib/x86_64-linux-gnu/libncurses.a(lib_mouse.o): In function >>> `_nc_mouse_event': > > Could you please post the content of > /usr/lib/x86_64-linux-gnu/pkgconfig/ncurses.pc ? > > > Thanks, > Gregor > Thanks for the quick reply, it's: $ cat /usr/lib/x86_64-linux-gnu/pkgconfig/ncurses.pc prefix=/usr exec_prefix=${prefix} libdir=/usr/lib/x86_64-linux-gnu includedir=${prefix}/include major_version=5 version=5.9.20110404 Name: ncurses Description: ncurses 5.9 library Version: ${version} Requires: tinfo Libs: -L${libdir} -lncurses Cflags: $ cat /usr/lib/x86_64-linux-gnu/pkgconfig/tinfo.pc prefix=/usr exec_prefix=${prefix} libdir=/usr/lib/x86_64-linux-gnu includedir=${prefix}/include major_version=5 version=5.9.20110404 Name: tinfo Description: ncurses 5.9 terminal interface library Version: ${version} Requires: Libs: -L${libdir} -ltinfo Cflags: Thanks, Axel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5119 bytes Desc: S/MIME Cryptographic Signature URL: From attila.krasznahorkay at gmail.com Tue Dec 8 04:09:13 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Tue, 8 Dec 2015 10:09:13 +0100 Subject: [cmake-developers] Proposal to teach cmDepends to only take dependencies from the source tree Message-ID: <86B42AB9-1BD5-49A3-921B-3FCB55D8D9B9@gmail.com> Dear All, In our software infrastructure I now got to the point that in building "high level" packages/projects the CMake build spends a very noticeable amount of time in calculating the dependencies of source files. To give you a feel of the issue, in one example that I was profiling, I build a small "package" that uses >180 other "packages", which at this point are all installed on a network file system (AFS). Those low level packages themselves depend on N external packages as well (like Boost, Oracle, etc.). So the include list for the build becomes very long, with most of the needed headers being outside of the source tree. In this case evaluating all the dependencies for a shared library made up of just 3 source files can take >10 seconds. I tried to find a way to tell CMake to ignore the dependencies that are outside of the source tree. As at this point for my use case those files can be considered fixed. I don't need to consider that they may change without me knowing. But as far as I could see, there is no mechanism in the code at the moment to achieve this. I did consider teaching cmDepends to only take non-system include paths into account for the dependency calculation. So that whatever is specified as a system include path, would be ignored. But since I found that GCC becomes significantly slower in building my sources if I specify >100 -isystem /afs/... paths to it compared to specifying all those paths with -I, I gave up on this idea. I also considered adding a new regular expression to cmDependsC to be able to specify using a regular expression which include paths to take into account and which to ignore. Which could still be a good idea to implement in cmDepends (not cmDependsC) later on, but for my own use case something simpler was enough. In the end I applied the following patch to CMake 3.4.1 locally to speed it up for my use case very significantly. Of course this is not a patch that could be applied to CMake for a general audience. But I do think that if this code/behaviour could be switched on using something like a directory property / global variable, a lot of users could make good use of it. As it can be a reasonable assumption in many development environments that only the changes inside of the source tree should be tracked by the build system. If you think that this is a good idea, I would be willing to provide some help in implementing it "properly" as well. Cheers, Attila -------------- next part -------------- A non-text attachment was scrubbed... Name: cmDepends-sourceOnly.diff Type: application/octet-stream Size: 1904 bytes Desc: not available URL: From ben.boeckel at kitware.com Tue Dec 8 11:14:07 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 8 Dec 2015 11:14:07 -0500 Subject: [cmake-developers] Proposal to teach cmDepends to only take dependencies from the source tree In-Reply-To: <86B42AB9-1BD5-49A3-921B-3FCB55D8D9B9@gmail.com> References: <86B42AB9-1BD5-49A3-921B-3FCB55D8D9B9@gmail.com> Message-ID: <20151208161407.GB2107@megas.khq.kitware.com> On Tue, Dec 08, 2015 at 10:09:13 +0100, Attila Krasznahorkay wrote: > In the end I applied the following patch to CMake 3.4.1 locally to > speed it up for my use case very significantly. Of course this is not > a patch that could be applied to CMake for a general audience. But I > do think that if this code/behaviour could be switched on using > something like a directory property / global variable, a lot of users > could make good use of it. As it can be a reasonable assumption in > many development environments that only the changes inside of the > source tree should be tracked by the build system. So some projects allow you to override specific headers (e.g., Boost) to provide which would be included from the source tree. This file is not included directly by any users of Boost (usually), but instead included via other Boost headers, so scanning of system includes can be important. So as long as there's an option/policy for it, I'm fine with the behavior. A policy could make it the default too with a directory property to re-enable global scanning. Hmm?the build tree should also probably be allowed as well. --Ben From neundorf at kde.org Tue Dec 8 15:46:13 2015 From: neundorf at kde.org (Alexander Neundorf) Date: Tue, 08 Dec 2015 21:46:13 +0100 Subject: [cmake-developers] Proposal to teach cmDepends to only take dependencies from the source tree In-Reply-To: <20151208161407.GB2107@megas.khq.kitware.com> References: <86B42AB9-1BD5-49A3-921B-3FCB55D8D9B9@gmail.com> <20151208161407.GB2107@megas.khq.kitware.com> Message-ID: <362406117.GZvUB7WoTK@tuxedo.neundorf.net> On Tuesday, December 08, 2015 11:14:07 Ben Boeckel wrote: > On Tue, Dec 08, 2015 at 10:09:13 +0100, Attila Krasznahorkay wrote: > > In the end I applied the following patch to CMake 3.4.1 locally to > > speed it up for my use case very significantly. Of course this is not > > a patch that could be applied to CMake for a general audience. But I > > do think that if this code/behaviour could be switched on using > > something like a directory property / global variable, a lot of users > > could make good use of it. As it can be a reasonable assumption in > > many development environments that only the changes inside of the > > source tree should be tracked by the build system. > > So some projects allow you to override specific headers (e.g., Boost) to > provide which would be included from the source > tree. This file is not included directly by any users of Boost > (usually), but instead included via other Boost headers, so scanning of > system includes can be important. > > So as long as there's an option/policy for it, I'm fine with the > behavior. A policy could make it the default too with a directory > property to re-enable global scanning. > > Hmm?the build tree should also probably be allowed as well. Yes. I think I have also seen projects where the "top level"-CMakeLists.txt is actually not at the root of the project, but in a subdir, e.g. cmake/. In that case all source files are outside ${CMAKE_SOURCE_DIR}. Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From gjasny at googlemail.com Tue Dec 8 16:51:11 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Tue, 8 Dec 2015 22:51:11 +0100 Subject: [cmake-developers] Please comment on ios-universal topic In-Reply-To: <1449060271344.76735@tomtom.com> References: <565DAD1B.60301@googlemail.com> <1449054144180.13106@tomtom.com> <1449060271344.76735@tomtom.com> Message-ID: <566750CF.9080007@googlemail.com> Hello, On 02/12/15 13:44, Bartosz Kosiorek wrote: > I would like to propose to rename property name to INSTALL_IOS_UNIVERSAL_LIBS. My thoughts about the property name: I added the necessary functionality to also combine Frameworks and App Bundles. So the _LIBS suffix now got misleading. And I think that providing a different property for libraries, frameworks and app bundles is not really helpful. To combine all targets one could set the CMAKE_ prefixed variable, to combine only some, one could set the property on the target itself. Deploying applications which support both armv7 (32bit) and armv8 (64bit) is already working by setting both architectures in the OSX_ARCHITECTURES property because both are covered by the device SDK. So technically we already support UNIVERSAL libraries. What we don't support is combining device and simulator builds. So how about replacing UNIVERSAL with COMBINED? IOS_INSTALL_COMBINED_BINARY I'm not sure if dropping the IOS bundle currently makes sense. At the moment just iOS (and watchOS, tvOS) is the odd platfrom which requires work-arounds. Thanks, Gregor From mantis at public.kitware.com Tue Dec 8 17:29:27 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 8 Dec 2015 17:29:27 -0500 Subject: [cmake-developers] [CMake 0015874]: Add command line flag to force ctest to exit with non-zero code when no tests are run Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15874 ====================================================================== Reported By: Kevin Wojniak Assigned To: ====================================================================== Project: CMake Issue ID: 15874 Category: CTest Reproducibility: always Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2015-12-08 17:29 EST Last Modified: 2015-12-08 17:29 EST ====================================================================== Summary: Add command line flag to force ctest to exit with non-zero code when no tests are run Description: If there is an error with how tests are configured, and ctest is run, it just outputs "No tests were found" and exits with code 0. For scripts that depend on ctest exit code reflecting whether tests succeeded or not, this fails. A flag should be set that forces a non-zero exit code when no tests are run. Otherwise the only way to handle this is to parse "No tests were found" but that is a hack and is not always possible. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-12-08 17:29 Kevin Wojniak New Issue ====================================================================== From attila.krasznahorkay at gmail.com Wed Dec 9 03:19:45 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Wed, 9 Dec 2015 09:19:45 +0100 Subject: [cmake-developers] Proposal to teach cmDepends to only take dependencies from the source tree In-Reply-To: <362406117.GZvUB7WoTK@tuxedo.neundorf.net> References: <86B42AB9-1BD5-49A3-921B-3FCB55D8D9B9@gmail.com> <20151208161407.GB2107@megas.khq.kitware.com> <362406117.GZvUB7WoTK@tuxedo.neundorf.net> Message-ID: <5EE91C0E-5CC5-4155-B4F8-9AE9FFBE3D09@gmail.com> Hi Alex, I never claimed that this simple proposal could be good for everyone. As far as I can see the main question is: If we implement an option in such a simple way (adding the binary dir to the search path as Ben very rightfully pointed out), would it be useful to a significant number of people? Or would we need to implement it in a more complicated way (possibly introducing a regular expression for selecting which include paths to include in the dependency generation) to make it useful for enough people? I myself am on the side of simplicity. Using regular expressions would allow us to do what I want. But if >95% of the people using this new possibility would use it exactly like I plan to, then implementing it in a more complicated way than necessary would just be a bad design choice. I'd leave the decision between these two possibility to you guys. I don't even want to argue that this should become the default behaviour in the future. I just argue that it should be possible to enable such a behaviour in some way if the user explicitly chooses to use it. Cheers, Attila > On 08 Dec 2015, at 21:46, Alexander Neundorf wrote: > > On Tuesday, December 08, 2015 11:14:07 Ben Boeckel wrote: > > On Tue, Dec 08, 2015 at 10:09:13 +0100, Attila Krasznahorkay wrote: > > > In the end I applied the following patch to CMake 3.4.1 locally to > > > speed it up for my use case very significantly. Of course this is not > > > a patch that could be applied to CMake for a general audience. But I > > > do think that if this code/behaviour could be switched on using > > > something like a directory property / global variable, a lot of users > > > could make good use of it. As it can be a reasonable assumption in > > > many development environments that only the changes inside of the > > > source tree should be tracked by the build system. > > > > So some projects allow you to override specific headers (e.g., Boost) to > > provide which would be included from the source > > tree. This file is not included directly by any users of Boost > > (usually), but instead included via other Boost headers, so scanning of > > system includes can be important. > > > > So as long as there's an option/policy for it, I'm fine with the > > behavior. A policy could make it the default too with a directory > > property to re-enable global scanning. > > > > Hmm?the build tree should also probably be allowed as well. > > Yes. > I think I have also seen projects where the "top level"-CMakeLists.txt is actually not at the root of the project, but in a subdir, e.g. cmake/. > In that case all source files are outside ${CMAKE_SOURCE_DIR}. > > Alex > From ruslan_baratov at yahoo.com Wed Dec 9 04:21:46 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Wed, 9 Dec 2015 16:21:46 +0700 Subject: [cmake-developers] Please comment on ios-universal topic In-Reply-To: <566750CF.9080007@googlemail.com> References: <565DAD1B.60301@googlemail.com> <1449054144180.13106@tomtom.com> <1449060271344.76735@tomtom.com> <566750CF.9080007@googlemail.com> Message-ID: <5667F2AA.6090909@yahoo.com> On 09-Dec-15 04:51, Gregor Jasny wrote: > Hello, > > On 02/12/15 13:44, Bartosz Kosiorek wrote: >> I would like to propose to rename property name to INSTALL_IOS_UNIVERSAL_LIBS. > My thoughts about the property name: > > I added the necessary functionality to also combine Frameworks and App > Bundles. So the _LIBS suffix now got misleading. And I think that > providing a different property for libraries, frameworks and app bundles > is not really helpful. To combine all targets one could set the CMAKE_ > prefixed variable, to combine only some, one could set the property on > the target itself. > > Deploying applications which support both armv7 (32bit) and armv8 > (64bit) is already working by setting both architectures in the > OSX_ARCHITECTURES property because both are covered by the device SDK. > > So technically we already support UNIVERSAL libraries. What we don't > support is combining device and simulator builds. So how about replacing > UNIVERSAL with COMBINED? > > IOS_INSTALL_COMBINED_BINARY Just to clarify you want to leave only one variable IOS_INSTALL_COMBINED_BINARY for the device + simulator on iOS platforms. Other platforms (in future) will be controlled by using *_ARCHITECTURES variables, right? Ruslo From yannsuisini at gmail.com Wed Dec 9 06:25:57 2015 From: yannsuisini at gmail.com (yann suisini) Date: Wed, 9 Dec 2015 12:25:57 +0100 Subject: [cmake-developers] Keil Armcc support Message-ID: Hi, Is theresomme support planned in a near future for the Keil / Armcc toolchain ? Regards, Yann Suisini -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at sap.com Wed Dec 9 08:02:04 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Wed, 9 Dec 2015 13:02:04 +0000 Subject: [cmake-developers] [CMake][PATCH] AIX RPATH handling Message-ID: <0410D8E8-A07E-467F-B2D7-CB98A9966CE8@sap.com> Hi, Attached is a patch for AIX enabling correct generation of executables regarding runtime path handling (currently, build paths could be stored as part of installed executables): option ?bnoipath is required for executables link command (currently, only shared libs link command get ?bnoipath option). Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-AIX-fix-erroneous-RPATH-handling-for-executables.patch Type: application/octet-stream Size: 2328 bytes Desc: 0001-AIX-fix-erroneous-RPATH-handling-for-executables.patch URL: From brad.king at kitware.com Wed Dec 9 08:59:59 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 9 Dec 2015 08:59:59 -0500 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: <5665D535.2070702@gmail.com> References: <5665B859.3050807@kitware.com> <5665D535.2070702@gmail.com> Message-ID: <566833DF.8080407@kitware.com> On 12/07/2015 01:51 PM, Michael Scott wrote: >> I noticed one glitch. I built against Qt 5.5.1 on Linux and the >> option dialog seems to truncate the labels. > I think I've fixed it, by using vertical layouts rather than form > layouts and setting the size policy to expanding for the widgets, if > that doesn't fix I'll need to look into QT in more depth as I've not got > much experience with it. Which Linux distro did you notice it in, looks > like gnome3? It is Debian 'testing' with KDE 5. Your changes fixed it for me. > Patches for the fix are attached. Thanks. Applied with slightly modified commit messages and merged to 'next' for testing: cmake-gui: Add options to control warning messages https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c1850455 cmake: Deduplicate warning message control code https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7f4a91ef -Brad From brad.king at kitware.com Wed Dec 9 09:00:08 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 9 Dec 2015 09:00:08 -0500 Subject: [cmake-developers] Keil Armcc support In-Reply-To: References: Message-ID: <566833E8.5040107@kitware.com> On 12/09/2015 06:25 AM, yann suisini wrote: > Is theresomme support planned in a near future for the > Keil / Armcc toolchain ? This was contributed recently: Add support for the ARM Compiler (arm.com) https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=035a658f http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14786 Please try it out from the development version to see how it goes. -Brad From brad.king at kitware.com Wed Dec 9 09:00:12 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 9 Dec 2015 09:00:12 -0500 Subject: [cmake-developers] [CMake][PATCH] AIX RPATH handling In-Reply-To: <0410D8E8-A07E-467F-B2D7-CB98A9966CE8@sap.com> References: <0410D8E8-A07E-467F-B2D7-CB98A9966CE8@sap.com> Message-ID: <566833EC.7090806@kitware.com> On 12/09/2015 08:02 AM, CHEVRIER, Marc wrote: > Attached is a patch for AIX enabling correct generation of executables > regarding runtime path handling (currently, build paths could be stored > as part of installed executables): option -bnoipath is required for > executables link command (currently, only shared libs link command > get -bnoipath option). Thanks. I agree that -bnoipath should be used for all linking because we never want the path to a library file to be encoded in its dependents. However, the proposed patch moves the flag over to the flags used to specify the RPATH. These may not be used if CMAKE_SKIP_RPATH or similar options are enabled. We should find another place for the flag that is always used for both shared libraries and executables. Thanks, -Brad From marc.chevrier at sap.com Wed Dec 9 09:09:43 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Wed, 9 Dec 2015 14:09:43 +0000 Subject: [cmake-developers] [CMake][PATCH] AIX RPATH handling In-Reply-To: <566833EC.7090806@kitware.com> References: <0410D8E8-A07E-467F-B2D7-CB98A9966CE8@sap.com> <566833EC.7090806@kitware.com> Message-ID: You are right. I missed this capability. My first idea was to apply to exec the same approach as for shared lib but I didn?t found appropriate variable: something like CMAKE_EXE_CREATE__FLAGS Or may be CMAKE_EXE_LINKER_FLAGS_INIT can be used but I am not sure of the usage of the *_INIT variables. Marc On 09/12/15 15:00, "Brad King" wrote: >On 12/09/2015 08:02 AM, CHEVRIER, Marc wrote: >> Attached is a patch for AIX enabling correct generation of executables >> regarding runtime path handling (currently, build paths could be stored >> as part of installed executables): option -bnoipath is required for >> executables link command (currently, only shared libs link command >> get -bnoipath option). > >Thanks. I agree that -bnoipath should be used for all linking because >we never want the path to a library file to be encoded in its dependents. >However, the proposed patch moves the flag over to the flags used to >specify the RPATH. These may not be used if CMAKE_SKIP_RPATH or similar >options are enabled. We should find another place for the flag that >is always used for both shared libraries and executables. > >Thanks, >-Brad > From brad.king at kitware.com Wed Dec 9 09:15:19 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 9 Dec 2015 09:15:19 -0500 Subject: [cmake-developers] [CMake][PATCH] AIX RPATH handling In-Reply-To: References: <0410D8E8-A07E-467F-B2D7-CB98A9966CE8@sap.com> <566833EC.7090806@kitware.com> Message-ID: <56683777.50605@kitware.com> On 12/09/2015 09:09 AM, CHEVRIER, Marc wrote: > You are right. I missed this capability. > My first idea was to apply to exec the same approach as for shared lib but I didn?t found appropriate variable: something like CMAKE_EXE_CREATE__FLAGS > Or may be CMAKE_EXE_LINKER_FLAGS_INIT can be used but I am not sure of the usage of the *_INIT variables. Actually the old code has it in two places: > - set(CMAKE_SHARED_LIBRARY_CREATE_${lang}_FLAGS "-G -Wl,-bnoipath") # -shared > - set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS "-Wl,-brtl,-bnoipath,-bexpall") # +s, flag for exe link to use shared lib The CREATE_ value is used when linking a shared library itself. The LINK_ value is used to link executables. Both should already be getting the flag with no changes. -Brad From ben.boeckel at kitware.com Wed Dec 9 09:38:55 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 9 Dec 2015 09:38:55 -0500 Subject: [cmake-developers] Proposal to teach cmDepends to only take dependencies from the source tree In-Reply-To: <5EE91C0E-5CC5-4155-B4F8-9AE9FFBE3D09@gmail.com> References: <86B42AB9-1BD5-49A3-921B-3FCB55D8D9B9@gmail.com> <20151208161407.GB2107@megas.khq.kitware.com> <362406117.GZvUB7WoTK@tuxedo.neundorf.net> <5EE91C0E-5CC5-4155-B4F8-9AE9FFBE3D09@gmail.com> Message-ID: <20151209143855.GA22671@megas.khq.kitware.com> On Wed, Dec 09, 2015 at 09:19:45 +0100, Attila Krasznahorkay wrote: > I myself am on the side of simplicity. Using regular expressions would > allow us to do what I want. But if >95% of the people using this new > possibility would use it exactly like I plan to, then implementing it > in a more complicated way than necessary would just be a bad design > choice. Do you have performance numbers for the change in your build between using include_directories (or target_include_directories), with and without SYSTEM, each with and without this change? --Ben From marc.chevrier at sap.com Wed Dec 9 09:41:54 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Wed, 9 Dec 2015 14:41:54 +0000 Subject: [cmake-developers] [CMake][PATCH] AIX RPATH handling In-Reply-To: <56683777.50605@kitware.com> References: <0410D8E8-A07E-467F-B2D7-CB98A9966CE8@sap.com> <566833EC.7090806@kitware.com> <56683777.50605@kitware.com> Message-ID: <519B81BA-F99D-4D2D-8573-1E33448AF5B9@sap.com> Oops ! You are right, on a simple example, all is OK. So the problem seems on my side. I will investigate this curious behaviour? Sorry for the noise. Marc On 09/12/15 15:15, "Brad King" wrote: >On 12/09/2015 09:09 AM, CHEVRIER, Marc wrote: >> You are right. I missed this capability. >> My first idea was to apply to exec the same approach as for shared lib but I didn?t found appropriate variable: something like CMAKE_EXE_CREATE__FLAGS >> Or may be CMAKE_EXE_LINKER_FLAGS_INIT can be used but I am not sure of the usage of the *_INIT variables. > >Actually the old code has it in two places: > >> - set(CMAKE_SHARED_LIBRARY_CREATE_${lang}_FLAGS "-G -Wl,-bnoipath") # -shared >> - set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS "-Wl,-brtl,-bnoipath,-bexpall") # +s, flag for exe link to use shared lib > >The CREATE_ value is used when linking a shared library itself. >The LINK_ value is used to link executables. Both should already >be getting the flag with no changes. > >-Brad > From mantis at public.kitware.com Wed Dec 9 10:57:44 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 9 Dec 2015 10:57:44 -0500 Subject: [cmake-developers] [CMake 0015875]: CMake does not find the VS2015 C compiler even though it has been installed by building a C/C++ program Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15875 ====================================================================== Reported By: philrosenberg Assigned To: ====================================================================== Project: CMake Issue ID: 15875 Category: CMake Reproducibility: have not tried Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-12-09 10:57 EST Last Modified: 2015-12-09 10:57 EST ====================================================================== Summary: CMake does not find the VS2015 C compiler even though it has been installed by building a C/C++ program Description: When running cmake with the Visual Studio 14 2015 generator cmake says it cannot find the C compiler. I have seen questions on stack exchange saying that the user needs to first build a C/C++ program to force VS to download the compiler. I have done this and I can see the compiler in C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin. Downgrading to 3.3.2 fixes the issue. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-12-09 10:57 philrosenberg New Issue ====================================================================== From attila.krasznahorkay at gmail.com Wed Dec 9 12:38:08 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Wed, 9 Dec 2015 18:38:08 +0100 Subject: [cmake-developers] Proposal to teach cmDepends to only take dependencies from the source tree In-Reply-To: <20151209143855.GA22671@megas.khq.kitware.com> References: <86B42AB9-1BD5-49A3-921B-3FCB55D8D9B9@gmail.com> <20151208161407.GB2107@megas.khq.kitware.com> <362406117.GZvUB7WoTK@tuxedo.neundorf.net> <5EE91C0E-5CC5-4155-B4F8-9AE9FFBE3D09@gmail.com> <20151209143855.GA22671@megas.khq.kitware.com> Message-ID: Hi Ben, Maybe I shouldn't advertise these pages here, but in the end they are not secret either. I only have hard numbers for the difference between specifying most of our includes with -isystem vs. specifying everything with -I. While still using SYSTEM includes, our full build took ~6 hours. http://atlas-nightlies-browser.cern.ch/~platinum/nightlies/info?tp=g&nightly=CMAKE&rel=rel_0&ar=x86_64-slc6-gcc49-opt Yesterday, after I updated the code to not use SYSTEM include paths anywhere, it went down to ~3 hours. http://atlas-nightlies-browser.cern.ch/~platinum/nightlies/info?tp=g&nightly=CMAKE&rel=rel_2&ar=x86_64-slc6-gcc49-opt I expect that the change in cmDepends will win us some more time over this. (I'm hoping for another 10% maybe.) But I don't have any firm numbers on that yet, as I didn't put my patched CMake version into our nightly build system yet. I just saw in some test jobs that rebuilding a small part of our software was a lot faster with this change. Cheers, Attila > On 09 Dec 2015, at 15:38, Ben Boeckel wrote: > > On Wed, Dec 09, 2015 at 09:19:45 +0100, Attila Krasznahorkay wrote: >> I myself am on the side of simplicity. Using regular expressions would >> allow us to do what I want. But if >95% of the people using this new >> possibility would use it exactly like I plan to, then implementing it >> in a more complicated way than necessary would just be a bad design >> choice. > > Do you have performance numbers for the change in your build between > using include_directories (or target_include_directories), with and > without SYSTEM, each with and without this change? > > --Ben From Bartosz.Kosiorek at tomtom.com Wed Dec 9 15:01:34 2015 From: Bartosz.Kosiorek at tomtom.com (Bartosz Kosiorek) Date: Wed, 9 Dec 2015 20:01:34 +0000 Subject: [cmake-developers] [PATCH] Support multiple directories by "cmake -E make_directory" command In-Reply-To: <1449673499979.53774@tomtom.com> References: <1449673499979.53774@tomtom.com> Message-ID: <1449691294774.40556@tomtom.com> Hello. With following patch, I have added support for multiple directories for make_directory command. ?Best Regards Bartosz -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Extend-make_directory-command-to-support-multiple-di.patch Type: text/x-patch Size: 6830 bytes Desc: 0001-Extend-make_directory-command-to-support-multiple-di.patch URL: From mantis at public.kitware.com Wed Dec 9 15:38:45 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 9 Dec 2015 15:38:45 -0500 Subject: [cmake-developers] [CMake 0015876]: "Cannot restore timestamp" Message-ID: <1af6a52a35f3fd91be561e3be8876b5a@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15876 ====================================================================== Reported By: A. Jesse Jiryu Davis Assigned To: ====================================================================== Project: CMake Issue ID: 15876 Category: CMake Reproducibility: random Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-12-09 15:38 EST Last Modified: 2015-12-09 15:38 EST ====================================================================== Summary: "Cannot restore timestamp" Description: Appears that bug http://public.kitware.com/Bug/view.php?id=13639 wasn't completely fixed, or has experienced a regression. With CMake 3.2.2 I very occasionally see this error at the end of an otherwise successful build on Windows: CUSTOMBUILD : CMake error : Cannot restore timestamp CMakeFiles\generate.stamp Steps to Reproduce: CMakeLists.txt with multiple add_library commands. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-12-09 15:38 A. Jesse Jiryu DavisNew Issue ====================================================================== From ben.boeckel at kitware.com Wed Dec 9 17:35:28 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 9 Dec 2015 17:35:28 -0500 Subject: [cmake-developers] set(CACHE) and the local scope Message-ID: <20151209223528.GA20586@megas.khq.kitware.com> Hi, So some behavior I was unaware of until today came up: set(var ON) option(var "description" OFF) message("var: ${var}") outputs "OFF" for the first configure and "ON" for subsequent configures. This is because set(var CACHE) does unset(var) *if* the cache was touched. This is not done on the second time around since it is already in the cache. I think a policy to remove the unset(var) behavior should be added since the current behavior means that clean builds can be wildly different than incremental builds. Related, I have a branch on the stage (update-variable-docs) which attempts to clarify some darker corners of the set() command and the *VARIABLES directory properties. Thoughts on the documentation updates and the policy? Thanks, --Ben From gjasny at googlemail.com Thu Dec 10 01:55:49 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Thu, 10 Dec 2015 07:55:49 +0100 Subject: [cmake-developers] Please comment on ios-universal topic In-Reply-To: <5667F2AA.6090909@yahoo.com> References: <565DAD1B.60301@googlemail.com> <1449054144180.13106@tomtom.com> <1449060271344.76735@tomtom.com> <566750CF.9080007@googlemail.com> <5667F2AA.6090909@yahoo.com> Message-ID: <566921F5.7040307@googlemail.com> Hello, On 09/12/15 10:21, Ruslan Baratov wrote: >> IOS_INSTALL_COMBINED_BINARY > > Just to clarify you want to leave only one variable > IOS_INSTALL_COMBINED_BINARY for the device + simulator on iOS platforms. > Other platforms (in future) will be controlled by using *_ARCHITECTURES > variables, right? Right. Any objections to that property name? Thanks, Gregor From marc.chevrier at sap.com Thu Dec 10 04:03:44 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Thu, 10 Dec 2015 09:03:44 +0000 Subject: [cmake-developers] [CMake][PATCH] AIX RPATH handling In-Reply-To: <519B81BA-F99D-4D2D-8573-1E33448AF5B9@sap.com> References: <0410D8E8-A07E-467F-B2D7-CB98A9966CE8@sap.com> <566833EC.7090806@kitware.com> <56683777.50605@kitware.com> <519B81BA-F99D-4D2D-8573-1E33448AF5B9@sap.com> Message-ID: <1ADCF7D4-F6C6-499A-98FA-41403F600131@sap.com> Hi, I identify the root of the problem: if I specify version 3.4 in cmake_minimum_required, generated link command (stored in file link.txt) for an executable does not contains value specified in variable CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS. Specifying 3.3 fix the problem. So this is a regression introduced in 3.4. Problem can be reproduced using this very simple CMakeLists.txt: cmake_minimum_required (VERSION 3.4) project (TEST LANGUAGES CXX) file (WRITE test.cpp "// empty\n") add_executable (test_exe test.cpp) This problem occurs on all platforms (tested on AIX and Linux). Marc On 09/12/15 15:41, "cmake-developers on behalf of CHEVRIER, Marc" wrote: > >Oops ! >You are right, on a simple example, all is OK. So the problem seems on my side. >I will investigate this curious behaviour? > >Sorry for the noise. > >Marc > > > > >On 09/12/15 15:15, "Brad King" wrote: > >>On 12/09/2015 09:09 AM, CHEVRIER, Marc wrote: >>> You are right. I missed this capability. >>> My first idea was to apply to exec the same approach as for shared lib but I didn?t found appropriate variable: something like CMAKE_EXE_CREATE__FLAGS >>> Or may be CMAKE_EXE_LINKER_FLAGS_INIT can be used but I am not sure of the usage of the *_INIT variables. >> >>Actually the old code has it in two places: >> >>> - set(CMAKE_SHARED_LIBRARY_CREATE_${lang}_FLAGS "-G -Wl,-bnoipath") # -shared >>> - set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS "-Wl,-brtl,-bnoipath,-bexpall") # +s, flag for exe link to use shared lib >> >>The CREATE_ value is used when linking a shared library itself. >>The LINK_ value is used to link executables. Both should already >>be getting the flag with no changes. >> >>-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 From ruslan_baratov at yahoo.com Thu Dec 10 06:16:58 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Thu, 10 Dec 2015 18:16:58 +0700 Subject: [cmake-developers] Please comment on ios-universal topic In-Reply-To: <566921F5.7040307@googlemail.com> References: <565DAD1B.60301@googlemail.com> <1449054144180.13106@tomtom.com> <1449060271344.76735@tomtom.com> <566750CF.9080007@googlemail.com> <5667F2AA.6090909@yahoo.com> <566921F5.7040307@googlemail.com> Message-ID: <56695F2A.4000403@yahoo.com> On 10-Dec-15 13:55, Gregor Jasny wrote: > Hello, > > On 09/12/15 10:21, Ruslan Baratov wrote: >>> IOS_INSTALL_COMBINED_BINARY >> >> Just to clarify you want to leave only one variable >> IOS_INSTALL_COMBINED_BINARY for the device + simulator on iOS platforms. >> Other platforms (in future) will be controlled by using *_ARCHITECTURES >> variables, right? > > Right. Any objections to that property name? > > Thanks, > Gregor TL;DR I'm finding it a little bit confusing but can't propose any better alternatives so I have no objections :) Some thoughts: * arm64 + armv7 is a universal binary, arm64 + armv7 + i386 - well, still universal binary too :) * OSX_ARCHITECTURES affect architectures on iOS. Probably it should be IOS_ARCHITECTURES or just ARCHITECTURES (though MACOSX_BUNDLE works same way) * OSX_ARCHITECTURES=armv7 -> build armv7, OSX_ARCHITECTURES=armv7,arm64 -> build universal armv7+arm64, but OSX_ARCHITECTURES=armv7,arm64,i386 doesn't build armv7+arm64+i386 binary * hard to say anything about future improvements, like if it will be easier to implement universal binary in build directory on Android, then *_ARCHITECTURES looks better. but if it will be easier to build one architecture then add extra code to add more on install then INSTALL_UNIVERSAL_BINARY for all platforms looks better Ruslo From brad.king at kitware.com Thu Dec 10 08:42:07 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 10 Dec 2015 08:42:07 -0500 Subject: [cmake-developers] [CMake][PATCH] AIX RPATH handling In-Reply-To: <1ADCF7D4-F6C6-499A-98FA-41403F600131@sap.com> References: <0410D8E8-A07E-467F-B2D7-CB98A9966CE8@sap.com> <566833EC.7090806@kitware.com> <56683777.50605@kitware.com> <519B81BA-F99D-4D2D-8573-1E33448AF5B9@sap.com> <1ADCF7D4-F6C6-499A-98FA-41403F600131@sap.com> Message-ID: <5669812F.1010300@kitware.com> On 12/10/2015 04:03 AM, CHEVRIER, Marc wrote: > I identify the root of the problem: if I specify version 3.4 in > cmake_minimum_required, generated link command (stored in file link.txt) > for an executable does not contains value specified in variable > CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS. Specifying 3.3 fix the problem. > So this is a regression introduced in 3.4. It is not technically a backward incompatibility because project code that worked in 3.3 will still work the same way in 3.4. Only after modifying the code to require 3.4 does the behavior change, but the new behavior is a regression. This is policy CMP0065: https://cmake.org/cmake/help/v3.4/policy/CMP0065.html introduced here: CMP0065: Restrict the use of CMAKE_SHARED_LIBRARY_LINK__FLAGS https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9784af1b The bug is that CMAKE_SHARED_LIBRARY_LINK__FLAGS is intended to be equivalent to "-rdynamic" on Linux, but the AIX platform file is using it for other flags too: > set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS "-Wl,-brtl,-bnoipath,-bexpall") This should be just set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS "-Wl,-bexpall") and the `-Wl,-brtl,-bnoipath` flags should move elsewhere. One could add them directly to the CMAKE_${lang}_LINK_EXECUTABLE command line, for example. Thanks, -Brad From marc.chevrier at sap.com Thu Dec 10 08:46:28 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Thu, 10 Dec 2015 13:46:28 +0000 Subject: [cmake-developers] [CMake][PATCH] AIX RPATH handling In-Reply-To: <5669812F.1010300@kitware.com> References: <0410D8E8-A07E-467F-B2D7-CB98A9966CE8@sap.com> <566833EC.7090806@kitware.com> <56683777.50605@kitware.com> <519B81BA-F99D-4D2D-8573-1E33448AF5B9@sap.com> <1ADCF7D4-F6C6-499A-98FA-41403F600131@sap.com> <5669812F.1010300@kitware.com> Message-ID: <751F175D-9A1D-46CD-821C-D12CB7562C41@sap.com> Ok. I see the problem. Thanks for your investigation. I will work on that and submit a patch to solve this problem. Marc On 10/12/15 14:42, "Brad King" wrote: >On 12/10/2015 04:03 AM, CHEVRIER, Marc wrote: >> I identify the root of the problem: if I specify version 3.4 in >> cmake_minimum_required, generated link command (stored in file link.txt) >> for an executable does not contains value specified in variable >> CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS. Specifying 3.3 fix the problem. >> So this is a regression introduced in 3.4. > >It is not technically a backward incompatibility because project code >that worked in 3.3 will still work the same way in 3.4. Only after >modifying the code to require 3.4 does the behavior change, but the >new behavior is a regression. This is policy CMP0065: > > https://cmake.org/cmake/help/v3.4/policy/CMP0065.html > >introduced here: > > CMP0065: Restrict the use of CMAKE_SHARED_LIBRARY_LINK__FLAGS > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9784af1b > >The bug is that CMAKE_SHARED_LIBRARY_LINK__FLAGS is intended >to be equivalent to "-rdynamic" on Linux, but the AIX platform file >is using it for other flags too: > >> set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS "-Wl,-brtl,-bnoipath,-bexpall") > >This should be just > > set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS "-Wl,-bexpall") > >and the `-Wl,-brtl,-bnoipath` flags should move elsewhere. One could >add them directly to the CMAKE_${lang}_LINK_EXECUTABLE command line, >for example. > >Thanks, >-Brad > From brad.king at kitware.com Thu Dec 10 08:50:10 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 10 Dec 2015 08:50:10 -0500 Subject: [cmake-developers] set(CACHE) and the local scope In-Reply-To: <20151209223528.GA20586@megas.khq.kitware.com> References: <20151209223528.GA20586@megas.khq.kitware.com> Message-ID: <56698312.1070403@kitware.com> On 12/09/2015 05:35 PM, Ben Boeckel wrote: > So some behavior I was unaware of until today came up: > > set(var ON) > option(var "description" OFF) > message("var: ${var}") > > outputs "OFF" for the first configure and "ON" for subsequent > configures. This is because set(var CACHE) does unset(var) *if* the > cache was touched. This is not done on the second time around since it > is already in the cache. That is a long-standing subtlety introduced without discussion, review, or tests here: BUG: change in how set cache overrides local definitions. Should mainly be a NOP change for most cases https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f52d37c2 IIRC there was confusion at the time in the case of set(var 1) set(var 2 CACHE STRING ...) message("${var}") # prints "1" before the above change. > I think a policy to remove the unset(var) behavior should be added since > the current behavior means that clean builds can be wildly different > than incremental builds. One reason a policy has not been introduced for this before is that producing a warning for the policy may be very verbose unless it is delayed until variable dereference, but the latter would be a huge performance hit to check. Still, I think things would be better off in the long run with some policy for it. > Related, I have a branch on the stage (update-variable-docs) which > attempts to clarify some darker corners of the set() command and the > *VARIABLES directory properties. The "LOCAL_VARIABLES" change uses "SCOPE_VARIABLES" in some places. The release note should only cover the new feature. -Brad From brad.king at kitware.com Thu Dec 10 09:09:12 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 10 Dec 2015 09:09:12 -0500 Subject: [cmake-developers] [PATCH] Support multiple directories by "cmake -E make_directory" command In-Reply-To: <1449691294774.40556@tomtom.com> References: <1449673499979.53774@tomtom.com> <1449691294774.40556@tomtom.com> Message-ID: <56698788.1060503@kitware.com> On 12/09/2015 03:01 PM, Bartosz Kosiorek wrote: > support for multiple directories for make_directory command. Thanks. Applied with minor documentation tweak: cmake: Teach -E make_directory to support multiple input directories https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7984ac5e -Brad From ben.boeckel at kitware.com Thu Dec 10 09:37:45 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 10 Dec 2015 09:37:45 -0500 Subject: [cmake-developers] set(CACHE) and the local scope In-Reply-To: <56698312.1070403@kitware.com> References: <20151209223528.GA20586@megas.khq.kitware.com> <56698312.1070403@kitware.com> Message-ID: <20151210143745.GA15763@megas.khq.kitware.com> On Thu, Dec 10, 2015 at 08:50:10 -0500, Brad King wrote: > That is a long-standing subtlety introduced without discussion, review, > or tests here: > > BUG: change in how set cache overrides local definitions. Should mainly be a NOP change for most cases > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f52d37c2 > > IIRC there was confusion at the time in the case of > > set(var 1) > set(var 2 CACHE STRING ...) > message("${var}") # prints "1" before the above change. The above commit has the same behavior as it does today: first configure != subsequent configure, so I don't see the confusion as being *less* after the fix since any existing tree wouldn't say "2" either, but I suppose it was something about dashboards doing clean builds. > On 12/09/2015 05:35 PM, Ben Boeckel wrote: > > I think a policy to remove the unset(var) behavior should be added since > > the current behavior means that clean builds can be wildly different > > than incremental builds. > > One reason a policy has not been introduced for this before is that > producing a warning for the policy may be very verbose unless it is > delayed until variable dereference, but the latter would be a huge > performance hit to check. Still, I think things would be better off > in the long run with some policy for it. Like with some of the more disruptive policies (e.g., CMP0054), it's a clarification of some potentially^Wconfusing behavior which can bite you in certain cases pretty hard (CI vs. developer builds). > The "LOCAL_VARIABLES" change uses "SCOPE_VARIABLES" in some places. > The release note should only cover the new feature. Oops. Updated. Also reordered the branch so the feature is at the end of the branch. --Ben From Bartosz.Kosiorek at tomtom.com Thu Dec 10 09:52:32 2015 From: Bartosz.Kosiorek at tomtom.com (Bartosz Kosiorek) Date: Thu, 10 Dec 2015 14:52:32 +0000 Subject: [cmake-developers] [Apple/iOS/OS X] Create subdirectories in Resource directory for Frameworks and Application bundle. Message-ID: <1449759153039.51334@tomtom.com> Hello. With CMake 3.5 it is possible to put Resources into the Bundle (Frameworks and Applications) More information: https://cmake.org/gitweb?p=cmake.git;a=blob;f=Help/prop_tgt/RESOURCE.rst So with code: add_executable(ExecutableTarget addDemo.c resourcefile.txt appresourcedir/appres.txt ) target_link_libraries(ExecutableTarget heymath mul) set(RESOURCE_FILES resourcefile.txt appresourcedir/appres.txt ) set_target_properties(ExecutableTarget PROPERTIES MACOSX_BUNDLE TRUE MACOSX_FRAMEWORK_IDENTIFIER org.cmake.ExecutableTarget RESOURCE "${RESOURCE_FILES}" ) For OS X systems it will produce following directory structure:: ExecutableTarget.app/ Contents Info.plist MacOS ExecutableTarget Resources appres.txt resourcefile.txt How it is officialy supported to tell CMake to create subdirectories inside "Resources" directory? As the result I would like to get, following directory structure: ExecutableTarget.app/ Contents/ Info.plist MacOS/ ExecutableTarget Resources/ appres.txt? appresourcedir/ ?resourcefile.txt? I would like to update documentation to describe how to do that. Thanks in advance Bartosz -------------- next part -------------- An HTML attachment was scrubbed... URL: From pavlina.chris at gmail.com Thu Dec 10 10:49:27 2015 From: pavlina.chris at gmail.com (Chris Pavlina) Date: Thu, 10 Dec 2015 10:49:27 -0500 Subject: [cmake-developers] [PATCH] Add Clang support to FindOpenMP Message-ID: <20151210154927.GA22708@turnip.localdomain> Hi, Attached is a patch to add the correct option for building OpenMP code using Clang. Per the llvm release notes it is necessary to give -fopenmp=libomp to build properly, not just -fopenmp. Tested on 64-bit Linux using clang 3.7.0. Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-Clang-support-to-FindOpenMP.patch Type: text/x-diff Size: 855 bytes Desc: not available URL: From brad.king at kitware.com Thu Dec 10 14:24:16 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 10 Dec 2015 14:24:16 -0500 Subject: [cmake-developers] [PATCH] Add Clang support to FindOpenMP In-Reply-To: <20151210154927.GA22708@turnip.localdomain> References: <20151210154927.GA22708@turnip.localdomain> Message-ID: <5669D160.7070003@kitware.com> On 12/10/2015 10:49 AM, Chris Pavlina wrote: > Attached is a patch to add the correct option for building OpenMP > code using Clang. Thanks, applied: FindOpenMP: Add Clang support https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1549927d -Brad From neundorf at kde.org Thu Dec 10 15:20:21 2015 From: neundorf at kde.org (Alexander Neundorf) Date: Thu, 10 Dec 2015 21:20:21 +0100 Subject: [cmake-developers] set(CACHE) and the local scope In-Reply-To: <20151209223528.GA20586@megas.khq.kitware.com> References: <20151209223528.GA20586@megas.khq.kitware.com> Message-ID: <2765707.8sBGggMN8k@tuxedo.neundorf.net> On Wednesday, December 09, 2015 17:35:28 Ben Boeckel wrote: > Hi, > > So some behavior I was unaware of until today came up: > > set(var ON) > option(var "description" OFF) > message("var: ${var}") Assuming I wouldn't know about the subtle characteristics of normal vs. cache variables, I think I would expect that var has the value of the option afterwards. I.e. on the first run it would be OFF (since that's the default value of the option), and all later runs it would have the value which is in the cache. Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Dec 10 15:26:54 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 10 Dec 2015 15:26:54 -0500 Subject: [cmake-developers] set(CACHE) and the local scope In-Reply-To: <2765707.8sBGggMN8k@tuxedo.neundorf.net> References: <20151209223528.GA20586@megas.khq.kitware.com> <2765707.8sBGggMN8k@tuxedo.neundorf.net> Message-ID: <5669E00E.5090309@kitware.com> On 12/10/2015 03:20 PM, Alexander Neundorf wrote: >> set(var ON) >> option(var "description" OFF) >> message("var: ${var}") > > I.e. on the first run it would be OFF (since that's the default value > of the option), and all later runs it would have the value which is in the cache. This is calling for the opposite change than Ben's proposal. Ben suggests never unsetting the local value to expose the cached value. Alex is suggesting always doing so, even if the cache option is not created by the command. Alternatively the option() or set(CACHE) commands could also set a local variable to the same value as the cache entry. This is pretty fundamental behavior so if we are going to mess with it through a policy we better get it right. -Brad From neundorf at kde.org Thu Dec 10 15:43:15 2015 From: neundorf at kde.org (Alexander Neundorf) Date: Thu, 10 Dec 2015 21:43:15 +0100 Subject: [cmake-developers] set(CACHE) and the local scope In-Reply-To: <5669E00E.5090309@kitware.com> References: <20151209223528.GA20586@megas.khq.kitware.com> <2765707.8sBGggMN8k@tuxedo.neundorf.net> <5669E00E.5090309@kitware.com> Message-ID: <1535142.RzdQ0dh9Ig@tuxedo.neundorf.net> On Thursday, December 10, 2015 15:26:54 Brad King wrote: > On 12/10/2015 03:20 PM, Alexander Neundorf wrote: > >> set(var ON) > >> option(var "description" OFF) > >> message("var: ${var}") > > > > I.e. on the first run it would be OFF (since that's the default value > > of the option), and all later runs it would have the value which is in the > > cache. > This is calling for the opposite change than Ben's proposal. Ben > suggests never unsetting the local value to expose the cached value. > Alex is suggesting always doing so, even if the cache option is > not created by the command. > > Alternatively the option() or set(CACHE) commands could also set > a local variable to the same value as the cache entry. > > This is pretty fundamental behavior so if we are going to mess with > it through a policy we better get it right. Yes. :-) My motivation: if the option() would just set/get the cache variable, and leave the local variable untouched, it would be a NOOP in the example above, and this is not obvious from seeing that code. Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Thu Dec 10 15:44:42 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 10 Dec 2015 15:44:42 -0500 Subject: [cmake-developers] set(CACHE) and the local scope In-Reply-To: <2765707.8sBGggMN8k@tuxedo.neundorf.net> References: <20151209223528.GA20586@megas.khq.kitware.com> <2765707.8sBGggMN8k@tuxedo.neundorf.net> Message-ID: <20151210204442.GA7402@megas.khq.kitware.com> On Thu, Dec 10, 2015 at 21:20:21 +0100, Alexander Neundorf wrote: > On Wednesday, December 09, 2015 17:35:28 Ben Boeckel wrote: > > So some behavior I was unaware of until today came up: > > > > set(var ON) > > option(var "description" OFF) > > message("var: ${var}") > > Assuming I wouldn't know about the subtle characteristics of normal vs. > cache variables, I think I would expect that var has the value of the option > afterwards. > > I.e. on the first run it would be OFF (since that's the default value of the > option), and all later runs it would have the value which is in the cache. The problem with this behavior is that if I do -Dinternal_var:BOOL=OFF, it will override any variable of that name inside the project and it cannot override it without knowing it is in the cache to unset it so that the local variable is used again. This behavior also breaks cmake_dependent_option as-is since it sets a local variable to the fallback value if its requirements are not met (which is how it remembers the user decision when it becomes a viable option again). --Ben From rleigh at codelibre.net Thu Dec 10 18:19:44 2015 From: rleigh at codelibre.net (rleigh at codelibre.net) Date: Thu, 10 Dec 2015 23:19:44 -0000 (GMT) Subject: [cmake-developers] [PATCH] Imported targets for FindGTest Message-ID: <132d5e9fddc5f60bc08f7705ec61e709.squirrel@g.mail.aa.net.uk> Pushed to https://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/gtest- imported-targets and merged into next for review and testing. - Adds GTest::GTest and GTest::Main imported targets (including Thread::Thread dependency for GTest::GTest and GTest::GTest for GTest::Main; the latter might not be appropriate and could be removed if needed--but I'm unaware of any situation where you would want to use GTest::Main without GTest::GTest) - Document imported targets - Update documentation, adding sections, description lists and updated examples - Add unit test to test imported targets and existing variables Kind regards, Roger From rleigh at codelibre.net Thu Dec 10 18:26:04 2015 From: rleigh at codelibre.net (rleigh at codelibre.net) Date: Thu, 10 Dec 2015 23:26:04 -0000 (GMT) Subject: [cmake-developers] [PATCH] Imported targets for FindGTest In-Reply-To: <132d5e9fddc5f60bc08f7705ec61e709.squirrel@g.mail.aa.net.uk> References: <132d5e9fddc5f60bc08f7705ec61e709.squirrel@g.mail.aa.net.uk> Message-ID: > - Adds GTest::GTest and GTest::Main imported targets (including > Thread::Thread dependency for GTest::GTest and GTest::GTest for > GTest::Main; the latter might not be appropriate and could be removed if > needed--but I'm unaware of any situation where you would want to use > GTest::Main without GTest::GTest) Double-checking the gtest_main symbol table, it depends on symbols from gtest, so the dependency is actually required, so please ignore the above--it's definitely appropriate. From nagger at gmx.de Thu Dec 10 18:29:05 2015 From: nagger at gmx.de (Nagger) Date: Fri, 11 Dec 2015 00:29:05 +0100 Subject: [cmake-developers] set(CACHE) and the local scope In-Reply-To: <5669E00E.5090309@kitware.com> References: <20151209223528.GA20586@megas.khq.kitware.com> <2765707.8sBGggMN8k@tuxedo.neundorf.net> <5669E00E.5090309@kitware.com> Message-ID: <566A0AC1.7040501@gmx.de> Am 10.12.2015 um 21:26 schrieb Brad King: > Alternatively the option() or set(CACHE) commands could also set a > local variable to the same value as the cache entry. I would vote for that. Maybe optional arguments to set(CACHE) could be introduced to switch the behavior. Like set(... CACHED ... [UNSET_LOCAL] [OVERWRITE_LOCAL] [KEEP_LOCAL]). What about locals in parent scopes, overwrite all of them? Bug https://public.kitware.com/Bug/view.php?id=15448 is kind of related, and also shows some weird effects of the current implementation. Marc From rleigh at codelibre.net Thu Dec 10 19:22:41 2015 From: rleigh at codelibre.net (rleigh at codelibre.net) Date: Fri, 11 Dec 2015 00:22:41 -0000 (GMT) Subject: [cmake-developers] [PATCH] Imported targets for FindGTest In-Reply-To: <132d5e9fddc5f60bc08f7705ec61e709.squirrel@g.mail.aa.net.uk> References: <132d5e9fddc5f60bc08f7705ec61e709.squirrel@g.mail.aa.net.uk> Message-ID: <84493d124378030ca44d1d3c4d33898e.squirrel@g.mail.aa.net.uk> > - Add unit test to test imported targets and existing variables I should mention that to run the unit test, you must define the GTEST_ROOT environment variable to point to the gtest build, due to gtest being annoyingly crippled to be uninstallable for dubious reasons. You can pass -DGTEST_ROOT, but since the cmake build can't pass it through without further changes, the environment variable is the only way to run the test with the existing patches. Regards, Roger From mantis at public.kitware.com Fri Dec 11 00:50:10 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 11 Dec 2015 00:50:10 -0500 Subject: [cmake-developers] [CMake 0015877]: Performance regression in file generation Message-ID: <2dbf9f6dc049338fcea73915e7e325b5@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15877 ====================================================================== Reported By: Jim King Assigned To: ====================================================================== Project: CMake Issue ID: 15877 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-12-11 00:50 EST Last Modified: 2015-12-11 00:50 EST ====================================================================== Summary: Performance regression in file generation Description: There was a significant performance regression between CMake 2.8 and 3.4 between "-- Configuring done" and "--Generating done" phases. We have a rather large project with a number of files and here are the timing results: CMake-3.4 39.27user 10.14system 0:50.62elapsed 97%CPU (0avgtext+0avgdata 119384maxresident)k 40inputs+167408outputs (0major+254266minor)pagefaults 0swaps CMake-2.8 21.97user 8.09system 0:32.09elapsed 93%CPU (0avgtext+0avgdata 163040maxresident)k 8400inputs+172200outputs (30major+266779minor)pagefaults 0swaps We're generating on Ubuntu 14.04 LTS with the command: CC=clang CXX=clang++ time /usr/bin/cmake -G"Eclipse CDT4 - Unix Makefiles" I could not find a defect for this so I decided to add one. Steps to Reproduce: See description. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-12-11 00:50 Jim King New Issue ====================================================================== From sschuberth at gmail.com Fri Dec 11 04:33:51 2015 From: sschuberth at gmail.com (Sebastian Schuberth) Date: Fri, 11 Dec 2015 10:33:51 +0100 Subject: [cmake-developers] Clarify on the ways to contribute Message-ID: Hi, while [1] clearly says that "The preferred entry point for new contributors is the mailing list", obviously also PRs at GitHub are merged [2]. Also, internally Kitware seems to use Gerrit [3], which for me would be the preferred place to submit and review patches. Could you please update [1] with all possible ways to contribute, and esp. mention whether GitHub PRs are now equally well accepted as posts on the mailing list? Thanks! PS: Please always email me directly as I chose to not receive mailing list posts. [1] https://github.com/Kitware/CMake/blob/master/CONTRIBUTING.rst [2] https://github.com/Kitware/CMake/pulls?q=is%3Apr+is%3Aclosed [3] http://review.source.kitware.com/ -- Sebastian Schuberth From marc.chevrier at sap.com Fri Dec 11 05:14:20 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Fri, 11 Dec 2015 10:14:20 +0000 Subject: [cmake-developers] [CMake][PATCH] Fix support of policy 0065 on AIX Message-ID: <396950B7-9C75-4FF9-AA11-180A00613004@sap.com> Hi, Attached is a patch to handle correctly policy 0065 and avoid lost of some required link flags (I.e. -bnoipath) Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-support-of-policy-0065-on-AIX.patch Type: application/octet-stream Size: 2792 bytes Desc: 0001-Fix-support-of-policy-0065-on-AIX.patch URL: From brad.king at kitware.com Fri Dec 11 08:35:28 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 11 Dec 2015 08:35:28 -0500 Subject: [cmake-developers] Clarify on the ways to contribute In-Reply-To: References: Message-ID: <566AD120.40804@kitware.com> On 12/11/2015 04:33 AM, Sebastian Schuberth wrote: > while [1] clearly says that "The preferred entry point for new > contributors is the mailing list", obviously also PRs at GitHub are > merged [2]. Also, internally Kitware seems to use Gerrit [3], which > for me would be the preferred place to submit and review patches. The mailing list is still the preferred method, but GitHub does not allow us to turn off PRs so we accept them for one-off simple changes. For larger changes we usually close the PR with a request to come here. The review.source.kitware.com site is used for some projects but is not suitable for CMake development due to lack of topic-level reviews. For now anyone taking the time to find and read CONTRIBUTING.rst should contribute through this mailing list as it requests. Thanks, -Brad From brad.king at kitware.com Fri Dec 11 09:27:23 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 11 Dec 2015 09:27:23 -0500 Subject: [cmake-developers] [CMake][PATCH] Fix support of policy 0065 on AIX In-Reply-To: <396950B7-9C75-4FF9-AA11-180A00613004@sap.com> References: <396950B7-9C75-4FF9-AA11-180A00613004@sap.com> Message-ID: <566ADD4B.9060604@kitware.com> On 12/11/2015 05:14 AM, CHEVRIER, Marc wrote: > Attached is a patch to handle correctly policy 0065 Thanks. I found that the same problem exists on HP-UX so I squashed in some changes for that too and applied: AIX,HP-UX: Fix RPATH handling when CMP0065 is set to NEW https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f254276f I've queued this for merge to the 'release' branch for 3.4.2. Thanks, -Brad From brad.king at kitware.com Fri Dec 11 09:36:07 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 11 Dec 2015 09:36:07 -0500 Subject: [cmake-developers] [Apple/iOS/OS X] Create subdirectories in Resource directory for Frameworks and Application bundle. In-Reply-To: <1449759153039.51334@tomtom.com> References: <1449759153039.51334@tomtom.com> Message-ID: <566ADF57.3070908@kitware.com> On 12/10/2015 09:52 AM, Bartosz Kosiorek wrote: > How it is officialy supported to tell CMake to create subdirectories > inside "Resources" directory? I'm not particularly familiar with this infrastructure myself, but I do not know of any way to define such a layout now. A new interface may have to be designed and implemented to achieve this. -Brad From brad.king at kitware.com Fri Dec 11 10:02:55 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 11 Dec 2015 10:02:55 -0500 Subject: [cmake-developers] [PATCH] Imported targets for FindGTest In-Reply-To: <84493d124378030ca44d1d3c4d33898e.squirrel@g.mail.aa.net.uk> References: <132d5e9fddc5f60bc08f7705ec61e709.squirrel@g.mail.aa.net.uk> <84493d124378030ca44d1d3c4d33898e.squirrel@g.mail.aa.net.uk> Message-ID: <566AE59F.9000108@kitware.com> On 12/10/2015 07:22 PM, rleigh at codelibre.net wrote: >> - Add unit test to test imported targets and existing variables > > I should mention that to run the unit test, you must define the GTEST_ROOT > environment variable to point to the gtest build, due to gtest being > annoyingly crippled to be uninstallable for dubious reasons. You can pass > -DGTEST_ROOT, but since the cmake build can't pass it through without > further changes, the environment variable is the only way to run the test > with the existing patches. Thanks. I've set this up on a nightly dashboard testing client and will look at it again once that is running. -Brad From sschuberth at gmail.com Fri Dec 11 10:14:56 2015 From: sschuberth at gmail.com (Sebastian Schuberth) Date: Fri, 11 Dec 2015 16:14:56 +0100 Subject: [cmake-developers] Clarify on the ways to contribute In-Reply-To: <566AD120.40804@kitware.com> References: <566AD120.40804@kitware.com> Message-ID: On Fri, Dec 11, 2015 at 2:35 PM, Brad King wrote: > The mailing list is still the preferred method, but GitHub does not > allow us to turn off PRs so we accept them for one-off simple changes. > For larger changes we usually close the PR with a request to come here. Thanks for the clarification. Still, I'd appreciate if this info went into CONTRIBUTING.rst. -- Sebastian Schuberth From clinton at elemtech.com Fri Dec 11 10:24:06 2015 From: clinton at elemtech.com (clinton at elemtech.com) Date: Fri, 11 Dec 2015 08:24:06 -0700 (MST) Subject: [cmake-developers] [Apple/iOS/OS X] Create subdirectories in Resource directory for Frameworks and Application bundle. In-Reply-To: <566ADF57.3070908@kitware.com> References: <1449759153039.51334@tomtom.com> <566ADF57.3070908@kitware.com> Message-ID: <1813369686.65723125.1449847446080.JavaMail.zimbra@elemtech.com> ----- On Dec 11, 2015, at 7:36 AM, Brad King brad.king at kitware.com wrote: > On 12/10/2015 09:52 AM, Bartosz Kosiorek wrote: >> How it is officialy supported to tell CMake to create subdirectories >> inside "Resources" directory? > > I'm not particularly familiar with this infrastructure myself, but I > do not know of any way to define such a layout now. A new interface > may have to be designed and implemented to achieve this. > > -Brad This may not be what you are looking for. You can place files in a bundle/framework at certain locations. Perhaps in subdirectories under Resources/. https://cmake.org/cmake/help/v3.4/prop_sf/MACOSX_PACKAGE_LOCATION.html Clint From Bartosz.Kosiorek at tomtom.com Fri Dec 11 12:01:41 2015 From: Bartosz.Kosiorek at tomtom.com (Bartosz Kosiorek) Date: Fri, 11 Dec 2015 17:01:41 +0000 Subject: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle. In-Reply-To: <1813369686.65723125.1449847446080.JavaMail.zimbra@elemtech.com> References: <1449759153039.51334@tomtom.com> <566ADF57.3070908@kitware.com>, <1813369686.65723125.1449847446080.JavaMail.zimbra@elemtech.com> Message-ID: <1449853301422.90915@tomtom.com> Thanks Clint Unfortunately MACOSX_PACKAGE_LOCATION is not working correctly with RESOURCE property. For every resource which is marked as RESOURCE, will be placed in root "Resources" directory. The CMake code below create following directory structure for OS X: ?? mul.framework ??? Headers -> Versions/Current/Headers ??? Resources -> Versions/Current/Resources ??? Versions ??? ??? A ??? ??? ??? Headers ??? ??? ??? ??? mul.h ??? ??? ??? Modules ??? ??? ??? ??? module.modulemap ??? ??? ??? Resources ??? ??? ??? ??? Info.plist ??? ??? ??? ??? mulres.txt ??? ??? ??? ??? pl.txt ??? ??? ??? ??? resourcefile.txt ??? ??? ??? lang ??? ??? ??? ??? en.txt ??? ??? ??? mul ??? ??? Current -> A ??? mul -> Versions/Current/mul As you can see eveything which is marked as "RESOURCE" will be placed in Versions/A/ directory My expectation will be that lang/pl.txt and lang/en.txt should be in Resources/lang/ directory. Here is complete directory structure: ?? mul.framework ??? Headers -> Versions/Current/Headers ??? Resources -> Versions/Current/Resources ??? Versions ??? ??? A ??? ??? ??? Headers ??? ??? ??? ??? mul.h ??? ??? ??? Modules ??? ??? ??? ??? module.modulemap ??? ??? ??? Resources ??? ??? ??? ??? Info.plist ??? ??? ??? ??? mulres.txt ??? ??? ??? ??? lang ??? ??? ??? ??? ??? pl.txt ??? ??? ??? ??? ??? en.txt ??? ??? ??? ??? resourcefile.txt ??? ??? ??? lang ??? ??? ??? ??? en.txt ??? ??? ??? mul ??? ??? Current -> A ??? mul -> Versions/Current/mul What do you think about that? Here is the source code: set_property(SOURCE module.modulemap PROPERTY MACOSX_PACKAGE_LOCATION "Modules") set_property( SOURCE lang/en.txt lang/pl.txt PROPERTY MACOSX_PACKAGE_LOCATION "lang") set(RESLIST mulres.txt lang/pl.txt resourcefile.txt ) add_library(mul SHARED mul.c mul.h module.modulemap lang/pl.txt lang/en.txt resourcefile.txt mulres.txt) # Create an iOS Framework bundle set_target_properties(mul PROPERTIES FRAMEWORK TRUE MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" PUBLIC_HEADER mul.h RESOURCE "${RESLIST}" ) Thanks in advance Bartosz ________________________________________ From: clinton at elemtech.com Sent: Friday, December 11, 2015 4:24 PM To: Brad King Cc: Bartosz Kosiorek; cmake-developers; Gregor Jasny Subject: Re: [Apple/iOS/OS X] Create subdirectories in Resource directory for Frameworks and Application bundle. ----- On Dec 11, 2015, at 7:36 AM, Brad King brad.king at kitware.com wrote: > On 12/10/2015 09:52 AM, Bartosz Kosiorek wrote: >> How it is officialy supported to tell CMake to create subdirectories >> inside "Resources" directory? > > I'm not particularly familiar with this infrastructure myself, but I > do not know of any way to define such a layout now. A new interface > may have to be designed and implemented to achieve this. > > -Brad This may not be what you are looking for. You can place files in a bundle/framework at certain locations. Perhaps in subdirectories under Resources/. https://cmake.org/cmake/help/v3.4/prop_sf/MACOSX_PACKAGE_LOCATION.html Clint From clinton at elemtech.com Fri Dec 11 13:06:04 2015 From: clinton at elemtech.com (Clinton Stimpson) Date: Fri, 11 Dec 2015 11:06:04 -0700 Subject: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle. In-Reply-To: <1449853301422.90915@tomtom.com> References: <1449759153039.51334@tomtom.com> <1813369686.65723125.1449847446080.JavaMail.zimbra@elemtech.com> <1449853301422.90915@tomtom.com> Message-ID: <2780526.IlfGfMxfeF@stryke> On Friday, December 11, 2015 05:01:41 PM Bartosz Kosiorek wrote: > Thanks Clint > > Unfortunately MACOSX_PACKAGE_LOCATION is not working correctly with RESOURCE > property. For every resource which is marked as RESOURCE, will be placed in > root "Resources" directory. > > The CMake code below create following directory structure for OS X: > > ?? mul.framework > ??? Headers -> Versions/Current/Headers > ??? Resources -> Versions/Current/Resources > ??? Versions > ? ??? A > ? ? ??? Headers > ? ? ? ??? mul.h > ? ? ??? Modules > ? ? ? ??? module.modulemap > ? ? ??? Resources > ? ? ? ??? Info.plist > ? ? ? ??? mulres.txt > ? ? ? ??? pl.txt > ? ? ? ??? resourcefile.txt > ? ? ??? lang > ? ? ? ??? en.txt > ? ? ??? mul > ? ??? Current -> A > ??? mul -> Versions/Current/mul > > > As you can see eveything which is marked as "RESOURCE" will be placed in > Versions/A/ directory My expectation will be that lang/pl.txt and > lang/en.txt should be in Resources/lang/ directory. Here is complete > directory structure: > > ?? mul.framework > ??? Headers -> Versions/Current/Headers > ??? Resources -> Versions/Current/Resources > ??? Versions > ? ??? A > ? ? ??? Headers > ? ? ? ??? mul.h > ? ? ??? Modules > ? ? ? ??? module.modulemap > ? ? ??? Resources > ? ? ? ??? Info.plist > ? ? ? ??? mulres.txt > ? ? ? ??? lang > ? ? ? ? ??? pl.txt > ? ? ? ? ??? en.txt > ? ? ? ??? resourcefile.txt > ? ? ??? lang > ? ? ? ??? en.txt > ? ? ??? mul > ? ??? Current -> A > ??? mul -> Versions/Current/mul > > > What do you think about that? > > Here is the source code: > > set_property(SOURCE module.modulemap > PROPERTY MACOSX_PACKAGE_LOCATION "Modules") > > set_property( > SOURCE lang/en.txt lang/pl.txt > PROPERTY MACOSX_PACKAGE_LOCATION "lang") > > set(RESLIST > mulres.txt > lang/pl.txt > resourcefile.txt > ) > > add_library(mul SHARED > mul.c > mul.h > module.modulemap > lang/pl.txt > lang/en.txt > resourcefile.txt > mulres.txt) > > # Create an iOS Framework bundle > set_target_properties(mul PROPERTIES > FRAMEWORK TRUE > MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul > MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 > MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 > XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" > PUBLIC_HEADER mul.h > RESOURCE "${RESLIST}" > ) Here is a CMakeLists.txt that will give you the desired layout. I also see that MACOSX_PACKAGE_LOCATION doesn't work with RESOURCE. set_property(SOURCE module.modulemap PROPERTY MACOSX_PACKAGE_LOCATION "Modules") set_property( SOURCE lang/pl.txt lang/en.txt PROPERTY MACOSX_PACKAGE_LOCATION "Resources/lang") set(RESLIST mulres.txt resourcefile.txt ) add_library(mul SHARED mul.c mul.h module.modulemap lang/pl.txt lang/en.txt resourcefile.txt mulres.txt) # Create an iOS Framework bundle set_target_properties(mul PROPERTIES FRAMEWORK TRUE MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" PUBLIC_HEADER mul.h RESOURCE "${RESLIST}" ) Now I'm wondering what does the RESOURCE target property do that MACOSX_PACKAGE_LOCATION doesn't already support? Clint From gang65 at poczta.onet.pl Fri Dec 11 13:44:17 2015 From: gang65 at poczta.onet.pl (Bartosz Kosiorek) Date: Fri, 11 Dec 2015 19:44:17 +0100 Subject: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle. In-Reply-To: <2780526.IlfGfMxfeF@stryke> References: <1449759153039.51334@tomtom.com> <1813369686.65723125.1449847446080.JavaMail.zimbra@elemtech.com> <1449853301422.90915@tomtom.com> <2780526.IlfGfMxfeF@stryke> Message-ID: Hi Because there is difference between OS X and iOS Bundles directory structure (see: Apple specification https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html), in trunk (In CMake 3.5) RESOURCE property create corresponding directory structure. I have already fix that with: https://public.kitware.com/Bug/view.php?id=15848 So RESOURCE gives you a level of abstraction: For OSX: it will create "Resource" directory For iOS it will create "flat" directory structure. In your example "Resource" directory will be created in both cases (for OSX and iOS). Which is wrong: For OSX: it should create "Resource" directory For iOS it will create "flat" directory structure. I could provide patch to fix that issue, if you agree with that. What do you think about that? Do you think the same should be applied to "Headers"? Best Regards Bartosz 2015-12-11 19:06 GMT+01:00 Clinton Stimpson : > > > On Friday, December 11, 2015 05:01:41 PM Bartosz Kosiorek wrote: > > Thanks Clint > > > > Unfortunately MACOSX_PACKAGE_LOCATION is not working correctly with > RESOURCE > > property. For every resource which is marked as RESOURCE, will be placed > in > > root "Resources" directory. > > > > The CMake code below create following directory structure for OS X: > > > > ?? mul.framework > > ??? Headers -> Versions/Current/Headers > > ??? Resources -> Versions/Current/Resources > > ??? Versions > > ? ??? A > > ? ? ??? Headers > > ? ? ? ??? mul.h > > ? ? ??? Modules > > ? ? ? ??? module.modulemap > > ? ? ??? Resources > > ? ? ? ??? Info.plist > > ? ? ? ??? mulres.txt > > ? ? ? ??? pl.txt > > ? ? ? ??? resourcefile.txt > > ? ? ??? lang > > ? ? ? ??? en.txt > > ? ? ??? mul > > ? ??? Current -> A > > ??? mul -> Versions/Current/mul > > > > > > As you can see eveything which is marked as "RESOURCE" will be placed in > > Versions/A/ directory My expectation will be that lang/pl.txt and > > lang/en.txt should be in Resources/lang/ directory. Here is complete > > directory structure: > > > > ?? mul.framework > > ??? Headers -> Versions/Current/Headers > > ??? Resources -> Versions/Current/Resources > > ??? Versions > > ? ??? A > > ? ? ??? Headers > > ? ? ? ??? mul.h > > ? ? ??? Modules > > ? ? ? ??? module.modulemap > > ? ? ??? Resources > > ? ? ? ??? Info.plist > > ? ? ? ??? mulres.txt > > ? ? ? ??? lang > > ? ? ? ? ??? pl.txt > > ? ? ? ? ??? en.txt > > ? ? ? ??? resourcefile.txt > > ? ? ??? lang > > ? ? ? ??? en.txt > > ? ? ??? mul > > ? ??? Current -> A > > ??? mul -> Versions/Current/mul > > > > > > What do you think about that? > > > > Here is the source code: > > > > set_property(SOURCE module.modulemap > > PROPERTY MACOSX_PACKAGE_LOCATION "Modules") > > > > set_property( > > SOURCE lang/en.txt lang/pl.txt > > PROPERTY MACOSX_PACKAGE_LOCATION "lang") > > > > set(RESLIST > > mulres.txt > > lang/pl.txt > > resourcefile.txt > > ) > > > > add_library(mul SHARED > > mul.c > > mul.h > > module.modulemap > > lang/pl.txt > > lang/en.txt > > resourcefile.txt > > mulres.txt) > > > > # Create an iOS Framework bundle > > set_target_properties(mul PROPERTIES > > FRAMEWORK TRUE > > MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul > > MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 > > MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 > > XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" > > PUBLIC_HEADER mul.h > > RESOURCE "${RESLIST}" > > ) > > > Here is a CMakeLists.txt that will give you the desired layout. > I also see that MACOSX_PACKAGE_LOCATION doesn't work with RESOURCE. > > > set_property(SOURCE module.modulemap > PROPERTY MACOSX_PACKAGE_LOCATION "Modules") > > set_property( > SOURCE lang/pl.txt lang/en.txt > PROPERTY MACOSX_PACKAGE_LOCATION "Resources/lang") > > set(RESLIST > mulres.txt > resourcefile.txt > ) > > add_library(mul SHARED > mul.c > mul.h > module.modulemap > lang/pl.txt > lang/en.txt > resourcefile.txt > mulres.txt) > > # Create an iOS Framework bundle > set_target_properties(mul PROPERTIES > FRAMEWORK TRUE > MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul > MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 > MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 > XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" > PUBLIC_HEADER mul.h > RESOURCE "${RESLIST}" > ) > > > Now I'm wondering what does the RESOURCE target property do that > MACOSX_PACKAGE_LOCATION doesn't already support? > > Clint > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Fri Dec 11 14:11:14 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 11 Dec 2015 14:11:14 -0500 Subject: [cmake-developers] [CMake 0015878]: CMake 3.4.1 can not find standalone Windows SDK 8.1 Message-ID: <46f34d5b2797396d3a837ed406ca52dd@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15878 ====================================================================== Reported By: Dmitry Sokolov Assigned To: ====================================================================== Project: CMake Issue ID: 15878 Category: CMake Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-12-11 14:11 EST Last Modified: 2015-12-11 14:11 EST ====================================================================== Summary: CMake 3.4.1 can not find standalone Windows SDK 8.1 Description: Installed components: * CMake 3.4.1 * Windows SDK 8.1 (standalone, https://msdn.microsoft.com/en-us/windows/desktop/bg162891.aspx) * Windows SDK 10 (standalone, https://dev.windows.com/en-us/downloads/windows-10-sdk) * Visual Studio Community 2015 with Update 1 (https://www.microsoft.com/en-us/download/details.aspx?id=49988) Launching CMake: cmake -G "Visual Studio 14 2015 ARM" ^ -D CMAKE_SYSTEM_NAME=WindowsStore ^ -D CMAKE_SYSTEM_VERSION=8.1 ^ -D CMAKE_MACHINE_TYPE="ARM" ^ -D CMAKE_C_COMPILER_WORKS=1 ^ -D CMAKE_CXX_COMPILER_WORKS=1 ^ -D CMAKE_SUPPRESS_REGENERATION=1 ^ -D CMAKE_BUILD_TYPE=Release ^ -D CMAKE_CONFIGURATION_TYPES=Release ^ -D CMAKE_SKIP_BUILD_ALL_DEPENDENCY=1 ^ x:/source CMake Error at CMakeLists.txt:20 (project): A Windows Store component with CMake requires both the Windows Desktop SDK as well as the Windows Store '8.1' SDK. Please make sure that you have both installed Additional Information: ========== Environment variables ========== CommandPromptType=Cross CommonProgramFiles=C:\Program Files\Common Files CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files CommonProgramW6432=C:\Program Files\Common Files ComSpec=C:\WINDOWS\system32\cmd.exe DevEnvDir=C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\ Framework40Version=v4.0 FrameworkDir=C:\WINDOWS\Microsoft.NET\Framework64 FrameworkDIR32=C:\WINDOWS\Microsoft.NET\Framework\ FrameworkDIR64=C:\WINDOWS\Microsoft.NET\Framework64 FrameworkVersion=v4.0.30319 FrameworkVersion32=v4.0.30319 FrameworkVersion64=v4.0.30319 INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ATLMFC\INCLUDE;C:\Program Files (x86)\Windows Kits\10\include\10.0.10586.0\ucrt;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\include\um;C:\Program Files (x86)\Windows Kits\8.1\include\shared;C:\Program Files (x86)\Windows Kits\8.1\include\um;C:\Program Files (x86)\Windows Kits\8.1\include\winrt;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ATLMFC\INCLUDE;C:\Program Files (x86)\Windows Kits\10\include\10.0.10586.0\ucrt;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\include\um;C:\Program Files (x86)\Windows Kits\8.1\include\shared;C:\Program Files (x86)\Windows Kits\8.1\include\um;C:\Program Files (x86)\Windows Kits\8.1\include\winrt; LIB=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\LIB\ARM;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ATLMFC\LIB\ARM;C:\Program Files (x86)\Windows Kits\10\lib\10.0.10586.0\ucrt\ARM;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\lib\um\ARM;C:\Program Files (x86)\Windows Kits\8.1\lib\winv6.3\um\ARM;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\LIB;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ATLMFC\LIB;C:\Program Files (x86)\Windows Kits\10\lib\10.0.10586.0\ucrt\x86;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\lib\um\x86;C:\Program Files (x86)\Windows Kits\8.1\lib\winv6.3\um\x86; LIBPATH=C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\LIB\ARM;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ATLMFC\LIB\ARM;C:\Program Files (x86)\Windows Kits\8.1\References\CommonConfiguration\Neutral;\Microsoft.VCLibs\14.0\References\CommonConfiguration\neutral;C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\LIB;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ATLMFC\LIB;C:\Program Files (x86)\Windows Kits\8.1\References\CommonConfiguration\Neutral;\Microsoft.VCLibs\14.0\References\CommonConfiguration\neutral; NETFXSDKDir=C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\ NUMBER_OF_PROCESSORS=4 OS=Windows_NT Path=C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow;C:\Program Files (x86)\MSBuild\14.0\bin\amd64;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64_arm;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64;C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\VCPackages;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools;C:\Program Files (x86)\HTML Help Workshop;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Performance Tools\x64;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Performance Tools;C:\Program Files (x86)\Windows Kits\8.1\bin\x64;C:\Program Files (x86)\Windows Kits\8.1\bin\x86;C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\x64\;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow;C:\Program Files (x86)\MSBuild\14.0\bin;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools;C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\VCPackages;C:\Program Files (x86)\HTML Help Workshop;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Performance Tools;C:\Program Files (x86)\Windows Kits\8.1\bin\x86;C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\twain_32\MF4010;C:\Dev\Tools\Ninja;C:\Dev\Tools\Jom;C:\Dev\Tools\TortoiseHg\;C:\Dev\Tools\TortoiseSVN\bin;C:\Dev\Tools\Msys2\mingw32\bin;C:\Dev\Tools\Msys2\usr\bin;C:\ProgramData\Oracle\Java\javapath;C:\Dev\Tools\Nodejs\;C:\Dev\Tools\TortoiseGit\bin;C:\Program Files (x86)\Skype\Phone\;C:\Dev\Tools\CMake\bin;D:\Users\Dmitry\AppData\Roaming\npm Platform=ARM PreferredToolArchitecture=x64 PROCESSOR_ARCHITECTURE=AMD64 PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 30 Stepping 5, GenuineIntel PROCESSOR_LEVEL=6 PROCESSOR_REVISION=1e05 ProgramData=C:\ProgramData ProgramFiles=C:\Program Files ProgramFiles(x86)=C:\Program Files (x86) ProgramW6432=C:\Program Files SystemRoot=C:\WINDOWS TEMP=B:\Temp TMP=B:\Temp UCRTVersion=10.0.10586.0 UniversalCRTSdkDir=C:\Program Files (x86)\Windows Kits\10\ user_inputversion=8.1 VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ VisualStudioVersion=14.0 VS110COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Tools\ VS120COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\ VS140COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\ VSINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 14.0\ windir=C:\WINDOWS WindowsLibPath=C:\Program Files (x86)\Windows Kits\8.1\References\CommonConfiguration\Neutral WindowsSdkDir=C:\Program Files (x86)\Windows Kits\8.1\ WindowsSDKLibVersion=winv6.3\ WindowsSDK_ExecutablePath_x64=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\x64\ WindowsSDK_ExecutablePath_x86=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\ ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-12-11 14:11 Dmitry Sokolov New Issue ====================================================================== From clinton at elemtech.com Fri Dec 11 14:21:24 2015 From: clinton at elemtech.com (clinton at elemtech.com) Date: Fri, 11 Dec 2015 12:21:24 -0700 (MST) Subject: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle. In-Reply-To: References: <1449759153039.51334@tomtom.com> <1813369686.65723125.1449847446080.JavaMail.zimbra@elemtech.com> <1449853301422.90915@tomtom.com> <2780526.IlfGfMxfeF@stryke> Message-ID: <910432174.66323078.1449861684460.JavaMail.zimbra@elemtech.com> ----- On Dec 11, 2015, at 11:44 AM, Bartosz Kosiorek wrote: > Hi > Because there is difference between OS X and iOS Bundles directory structure > (see: Apple specification > https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html > ), > in trunk (In CMake 3.5) RESOURCE property create corresponding directory > structure. > I have already fix that with: > https://public.kitware.com/Bug/view.php?id=15848 Ok. I hadn't been following all your work. Also, I didn't see a toggle in the CMake code you sent to choose an iOS bundle instead of OS X bundles. How is that toggled? > So RESOURCE gives you a level of abstraction: > For OSX: > it will create "Resource" directory > For iOS it will create "flat" directory structure. > In your example "Resource" directory will be created in both cases (for OSX and > iOS). > Which is wrong: > For OSX: it should create "Resource" directory > For iOS it will create "flat" directory structure. > I could provide patch to fix that issue, if you agree with that. > What do you think about that? > Do you think the same should be applied to "Headers"? I think the abstraction seems reasonable, as well as what you are proposing. However, I'm not an Apple guru. I wonder if there are other Apple experts that can weigh in this if better feedback is needed. Clint > Best Regards > Bartosz > 2015-12-11 19:06 GMT+01:00 Clinton Stimpson < clinton at elemtech.com > : >> On Friday, December 11, 2015 05:01:41 PM Bartosz Kosiorek wrote: >> > Thanks Clint >> > Unfortunately MACOSX_PACKAGE_LOCATION is not working correctly with RESOURCE >> > property. For every resource which is marked as RESOURCE, will be placed in >> > root "Resources" directory. >> > The CMake code below create following directory structure for OS X: >> > ?? mul.framework >> > ??? Headers -> Versions/Current/Headers >> > ??? Resources -> Versions/Current/Resources >> > ??? Versions >> > ? ??? A >> > ? ? ??? Headers >> > ? ? ? ??? mul.h >> > ? ? ??? Modules >> > ? ? ? ??? module.modulemap >> > ? ? ??? Resources >> > ? ? ? ??? Info.plist >> > ? ? ? ??? mulres.txt >> > ? ? ? ??? pl.txt >> > ? ? ? ??? resourcefile.txt >> > ? ? ??? lang >> > ? ? ? ??? en.txt >> > ? ? ??? mul >> > ? ??? Current -> A >> > ??? mul -> Versions/Current/mul >> > As you can see eveything which is marked as "RESOURCE" will be placed in >> > Versions/A/ directory My expectation will be that lang/pl.txt and >> > lang/en.txt should be in Resources/lang/ directory. Here is complete >> > directory structure: >> > ?? mul.framework >> > ??? Headers -> Versions/Current/Headers >> > ??? Resources -> Versions/Current/Resources >> > ??? Versions >> > ? ??? A >> > ? ? ??? Headers >> > ? ? ? ??? mul.h >> > ? ? ??? Modules >> > ? ? ? ??? module.modulemap >> > ? ? ??? Resources >> > ? ? ? ??? Info.plist >> > ? ? ? ??? mulres.txt >> > ? ? ? ??? lang >> > ? ? ? ? ??? pl.txt >> > ? ? ? ? ??? en.txt >> > ? ? ? ??? resourcefile.txt >> > ? ? ??? lang >> > ? ? ? ??? en.txt >> > ? ? ??? mul >> > ? ??? Current -> A >> > ??? mul -> Versions/Current/mul >> > What do you think about that? >> > Here is the source code: >> > set_property(SOURCE module.modulemap >> > PROPERTY MACOSX_PACKAGE_LOCATION "Modules") >> > set_property( >> > SOURCE lang/en.txt lang/pl.txt >> > PROPERTY MACOSX_PACKAGE_LOCATION "lang") >> > set(RESLIST >> > mulres.txt >> > lang/pl.txt >> > resourcefile.txt >> > ) >> > add_library(mul SHARED >> > mul.c >> > mul.h >> > module.modulemap >> > lang/pl.txt >> > lang/en.txt >> > resourcefile.txt >> > mulres.txt) >> > # Create an iOS Framework bundle >> > set_target_properties(mul PROPERTIES >> > FRAMEWORK TRUE >> > MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul >> > MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 >> > MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 >> > XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" >> > PUBLIC_HEADER mul.h >> > RESOURCE "${RESLIST}" >> > ) >> Here is a CMakeLists.txt that will give you the desired layout. >> I also see that MACOSX_PACKAGE_LOCATION doesn't work with RESOURCE. >> set_property(SOURCE module.modulemap >> PROPERTY MACOSX_PACKAGE_LOCATION "Modules") >> set_property( >> SOURCE lang/pl.txt lang/en.txt >> PROPERTY MACOSX_PACKAGE_LOCATION "Resources/lang") >> set(RESLIST >> mulres.txt >> resourcefile.txt >> ) >> add_library(mul SHARED >> mul.c >> mul.h >> module.modulemap >> lang/pl.txt >> lang/en.txt >> resourcefile.txt >> mulres.txt) >> # Create an iOS Framework bundle >> set_target_properties(mul PROPERTIES >> FRAMEWORK TRUE >> MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul >> MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 >> MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 >> XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" >> PUBLIC_HEADER mul.h >> RESOURCE "${RESLIST}" >> ) >> Now I'm wondering what does the RESOURCE target property do that >> MACOSX_PACKAGE_LOCATION doesn't already support? >> Clint >> -- >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Fri Dec 11 14:44:39 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 11 Dec 2015 14:44:39 -0500 Subject: [cmake-developers] set(CACHE) and the local scope In-Reply-To: <56698312.1070403@kitware.com> References: <20151209223528.GA20586@megas.khq.kitware.com> <56698312.1070403@kitware.com> Message-ID: <20151211194439.GD26622@megas.khq.kitware.com> On Thu, Dec 10, 2015 at 08:50:10 -0500, Brad King wrote: > BUG: change in how set cache overrides local definitions. Should mainly be a NOP change for most cases > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f52d37c2 So Brad and I discussed today the reasons behind this change. Here is the thread behind the cause for the change: http://public.kitware.com/pipermail/cmake/2007-March/013198.html The problem was this pattern: function (set_cache var value) set("${var}" "${value}" CACHE INTERNAL "docs") endfunction () set(some_var value CACHE INTERNAL "docs") set_cache(some_var other_value) message("${some_var}") Before this change, "value" would be output because the first set(CACHE) would set `some_var` to `value` in the local scope, but afterwards, because the variable is unset, the cache would be queried directly and "other_value" would be output. ####### For work related to any changes to the interactions between the local scope and the cache, here is the baseline that must be met: The first configure must not differ from subsequent configures. set(CACHE) using either FORCE or the INTERNAL type do not have this problem currently since they always touch the local scope as well. I don't think anyone is going to disagree that the existing behavior is a problem in this regard, so the question is which behavior to prefer (whether set(CACHE) has other optional arguments to select a specific behavior or not is a separate question): Option 1: set(CACHE) always pulls from the cache into the local scope (first configure behavior is canonical) Option 2: set(CACHE) never touches the local scope (subsequent configure behavior is canonical) The main benefit of the first option is that reading the code is more "logical" in that set(CACHE) always does something to that variable (makes the cache's value available as ${var}). The value is unpredictable since the user can always set the cache to some bogus value (the STRINGS property or type hints will not save you because -D exists). The main benefit of the second option is that projects embedding external projects could override cache variables inside of that project without set(CACHE INTERNAL) (which doesn't help in the case of FORCE or INTERNAL variables that inner project uses anyways). A third option that Brad and I brainstormed after tracking down various bits of history and thinking about the behaviors is: Option 3: set(CACHE) (and any other cache-touching behavior) does *nothing* with the cache if a local variable by that name is defined This has the benefits of the second in that superset projects can set projects *and* hide cache values with a single set() command and also caches become less cluttered (e.g., if you set PYTHON_EXECUTABLE explicitly, the cache entry for FindPythonInterp doesn't appear and since the project is presumably forcing the value using a local variable, that is what is wanted anyways, so don't let the user mess that up). This policy would become an invasive change (there are 40 (+6 if you count cmCPluginAPI) call sites of cmMakefile::AddCacheDefinition that need audited for behavior changes due to whatever policy behavior is chosen. Thoughts? --Ben From robert.maynard at kitware.com Fri Dec 11 15:38:47 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 11 Dec 2015 15:38:47 -0500 Subject: [cmake-developers] set(CACHE) and the local scope In-Reply-To: <20151211194439.GD26622@megas.khq.kitware.com> References: <20151209223528.GA20586@megas.khq.kitware.com> <56698312.1070403@kitware.com> <20151211194439.GD26622@megas.khq.kitware.com> Message-ID: I like the sounds of both Option 1, and Option 2. I feel Option 3 is really bad. We should remember that people understand/are taught the current CMake behavior of local variables being preferred over cache variables. If we move to Option 3, that rule becomes "local variables are preferred over cache variables, and cache variables are not constructed if a local variable exists ( even if unset? ) with the same name.". I can already imagine people writing functions that try to set cache variables, but can't since a local function variable is blocking them. On Fri, Dec 11, 2015 at 2:44 PM, Ben Boeckel wrote: > On Thu, Dec 10, 2015 at 08:50:10 -0500, Brad King wrote: > > BUG: change in how set cache overrides local definitions. Should mainly > be a NOP change for most cases > > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f52d37c2 > > So Brad and I discussed today the reasons behind this change. Here is > the thread behind the cause for the change: > > http://public.kitware.com/pipermail/cmake/2007-March/013198.html > > The problem was this pattern: > > function (set_cache var value) > set("${var}" "${value}" CACHE INTERNAL "docs") > endfunction () > > set(some_var value CACHE INTERNAL "docs") > set_cache(some_var other_value) > message("${some_var}") > > Before this change, "value" would be output because the first set(CACHE) > would set `some_var` to `value` in the local scope, but afterwards, > because the variable is unset, the cache would be queried directly and > "other_value" would be output. > > ####### > > For work related to any changes to the interactions between the local > scope and the cache, here is the baseline that must be met: > > The first configure must not differ from subsequent configures. > > set(CACHE) using either FORCE or the INTERNAL type do not have this > problem currently since they always touch the local scope as well. I > don't think anyone is going to disagree that the existing behavior is a > problem in this regard, so the question is which behavior to prefer > (whether set(CACHE) has other optional arguments to select a specific > behavior or not is a separate question): > > Option 1: > > set(CACHE) always pulls from the cache into the local scope (first > configure behavior is canonical) > > Option 2: > > set(CACHE) never touches the local scope (subsequent configure > behavior is canonical) > > The main benefit of the first option is that reading the code is more > "logical" in that set(CACHE) always does something to that variable > (makes the cache's value available as ${var}). The value is > unpredictable since the user can always set the cache to some bogus > value (the STRINGS property or type hints will not save you because -D > exists). > > The main benefit of the second option is that projects embedding > external projects could override cache variables inside of that project > without set(CACHE INTERNAL) (which doesn't help in the case of FORCE or > INTERNAL variables that inner project uses anyways). > > A third option that Brad and I brainstormed after tracking down various > bits of history and thinking about the behaviors is: > > Option 3: > > set(CACHE) (and any other cache-touching behavior) does *nothing* > with the cache if a local variable by that name is defined > > This has the benefits of the second in that superset projects can set > projects *and* hide cache values with a single set() command and also > caches become less cluttered (e.g., if you set PYTHON_EXECUTABLE > explicitly, the cache entry for FindPythonInterp doesn't appear and > since the project is presumably forcing the value using a local > variable, that is what is wanted anyways, so don't let the user mess > that up). > > This policy would become an invasive change (there are 40 (+6 if you > count cmCPluginAPI) call sites of cmMakefile::AddCacheDefinition that > need audited for behavior changes due to whatever policy behavior is > chosen. > > Thoughts? > > --Ben > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bartosz.Kosiorek at tomtom.com Fri Dec 11 15:46:56 2015 From: Bartosz.Kosiorek at tomtom.com (Bartosz Kosiorek) Date: Fri, 11 Dec 2015 20:46:56 +0000 Subject: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle. In-Reply-To: <910432174.66323078.1449861684460.JavaMail.zimbra@elemtech.com> References: <1449759153039.51334@tomtom.com> <1813369686.65723125.1449847446080.JavaMail.zimbra@elemtech.com> <1449853301422.90915@tomtom.com> <2780526.IlfGfMxfeF@stryke> , <910432174.66323078.1449861684460.JavaMail.zimbra@elemtech.com> Message-ID: <1449866813173.56940@tomtom.com> Hi To enable iOS build, I'm using following settings in CMakeLists.txt: set(APPLE_PLATFORM "iphonesimulator") set(CMAKE_OSX_SYSROOT "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk") set(CMAKE_C_FLAGS "-isysroot ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0") set(CMAKE_CXX_FLAGS "-isysroot ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0") Do you think it should be documented? Where is the good place to do so? Maybe somewhere here: https://cmake.org/cmake/help/v3.4/variable/CMAKE_OSX_SYSROOT.html What do you think? ? ________________________________ From: clinton at elemtech.com Sent: Friday, December 11, 2015 8:21 PM To: Bartosz Kosiorek Cc: Bartosz Kosiorek; cmake-developers; Gregor Jasny Subject: Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle. ----- On Dec 11, 2015, at 11:44 AM, Bartosz Kosiorek wrote: Hi Because there is difference between OS X and iOS Bundles directory structure (see: Apple specification https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html), in trunk (In CMake 3.5) RESOURCE property create corresponding directory structure. I have already fix that with: https://public.kitware.com/Bug/view.php?id=15848 Ok. I hadn't been following all your work. Also, I didn't see a toggle in the CMake code you sent to choose an iOS bundle instead of OS X bundles. How is that toggled? So RESOURCE gives you a level of abstraction: For OSX: it will create "Resource" directory For iOS it will create "flat" directory structure. In your example "Resource" directory will be created in both cases (for OSX and iOS). Which is wrong: For OSX: it should create "Resource" directory For iOS it will create "flat" directory structure. I could provide patch to fix that issue, if you agree with that. What do you think about that? Do you think the same should be applied to "Headers"? I think the abstraction seems reasonable, as well as what you are proposing. However, I'm not an Apple guru. I wonder if there are other Apple experts that can weigh in this if better feedback is needed. Clint Best Regards Bartosz 2015-12-11 19:06 GMT+01:00 Clinton Stimpson >: On Friday, December 11, 2015 05:01:41 PM Bartosz Kosiorek wrote: > Thanks Clint > > Unfortunately MACOSX_PACKAGE_LOCATION is not working correctly with RESOURCE > property. For every resource which is marked as RESOURCE, will be placed in > root "Resources" directory. > > The CMake code below create following directory structure for OS X: > > ?? mul.framework > ??? Headers -> Versions/Current/Headers > ??? Resources -> Versions/Current/Resources > ??? Versions > ? ??? A > ? ? ??? Headers > ? ? ? ??? mul.h > ? ? ??? Modules > ? ? ? ??? module.modulemap > ? ? ??? Resources > ? ? ? ??? Info.plist > ? ? ? ??? mulres.txt > ? ? ? ??? pl.txt > ? ? ? ??? resourcefile.txt > ? ? ??? lang > ? ? ? ??? en.txt > ? ? ??? mul > ? ??? Current -> A > ??? mul -> Versions/Current/mul > > > As you can see eveything which is marked as "RESOURCE" will be placed in > Versions/A/ directory My expectation will be that lang/pl.txt and > lang/en.txt should be in Resources/lang/ directory. Here is complete > directory structure: > > ?? mul.framework > ??? Headers -> Versions/Current/Headers > ??? Resources -> Versions/Current/Resources > ??? Versions > ? ??? A > ? ? ??? Headers > ? ? ? ??? mul.h > ? ? ??? Modules > ? ? ? ??? module.modulemap > ? ? ??? Resources > ? ? ? ??? Info.plist > ? ? ? ??? mulres.txt > ? ? ? ??? lang > ? ? ? ? ??? pl.txt > ? ? ? ? ??? en.txt > ? ? ? ??? resourcefile.txt > ? ? ??? lang > ? ? ? ??? en.txt > ? ? ??? mul > ? ??? Current -> A > ??? mul -> Versions/Current/mul > > > What do you think about that? > > Here is the source code: > > set_property(SOURCE module.modulemap > PROPERTY MACOSX_PACKAGE_LOCATION "Modules") > > set_property( > SOURCE lang/en.txt lang/pl.txt > PROPERTY MACOSX_PACKAGE_LOCATION "lang") > > set(RESLIST > mulres.txt > lang/pl.txt > resourcefile.txt > ) > > add_library(mul SHARED > mul.c > mul.h > module.modulemap > lang/pl.txt > lang/en.txt > resourcefile.txt > mulres.txt) > > # Create an iOS Framework bundle > set_target_properties(mul PROPERTIES > FRAMEWORK TRUE > MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul > MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 > MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 > XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" > PUBLIC_HEADER mul.h > RESOURCE "${RESLIST}" > ) Here is a CMakeLists.txt that will give you the desired layout. I also see that MACOSX_PACKAGE_LOCATION doesn't work with RESOURCE. set_property(SOURCE module.modulemap PROPERTY MACOSX_PACKAGE_LOCATION "Modules") set_property( SOURCE lang/pl.txt lang/en.txt PROPERTY MACOSX_PACKAGE_LOCATION "Resources/lang") set(RESLIST mulres.txt resourcefile.txt ) add_library(mul SHARED mul.c mul.h module.modulemap lang/pl.txt lang/en.txt resourcefile.txt mulres.txt) # Create an iOS Framework bundle set_target_properties(mul PROPERTIES FRAMEWORK TRUE MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" PUBLIC_HEADER mul.h RESOURCE "${RESLIST}" ) Now I'm wondering what does the RESOURCE target property do that MACOSX_PACKAGE_LOCATION doesn't already support? Clint -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From neundorf at kde.org Fri Dec 11 16:13:46 2015 From: neundorf at kde.org (Alexander Neundorf) Date: Fri, 11 Dec 2015 22:13:46 +0100 Subject: [cmake-developers] set(CACHE) and the local scope In-Reply-To: <20151211194439.GD26622@megas.khq.kitware.com> References: <20151209223528.GA20586@megas.khq.kitware.com> <56698312.1070403@kitware.com> <20151211194439.GD26622@megas.khq.kitware.com> Message-ID: <1483681.CMANjG64Xx@tuxedo.neundorf.net> On Friday, December 11, 2015 14:44:39 Ben Boeckel wrote: ... > Option 3: > > set(CACHE) (and any other cache-touching behavior) does *nothing* > with the cache if a local variable by that name is defined just to clarify: and also does nothing to the local variable ? Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From clinton at elemtech.com Fri Dec 11 16:16:34 2015 From: clinton at elemtech.com (Clinton Stimpson) Date: Fri, 11 Dec 2015 14:16:34 -0700 Subject: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle. In-Reply-To: <1449866813173.56940@tomtom.com> References: <1449759153039.51334@tomtom.com> <910432174.66323078.1449861684460.JavaMail.zimbra@elemtech.com> <1449866813173.56940@tomtom.com> Message-ID: <2235818.ev9kN26Y2h@stryke> On Friday, December 11, 2015 08:46:56 PM Bartosz Kosiorek wrote: > Hi > > To enable iOS build, I'm using following settings in CMakeLists.txt: > > > set(APPLE_PLATFORM "iphonesimulator") > set(CMAKE_OSX_SYSROOT > "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platf > orm/Developer/SDKs/iPhoneSimulator.sdk") set(CMAKE_C_FLAGS "-isysroot > ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0") set(CMAKE_CXX_FLAGS "-isysroot > ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0") > Do you think it should be documented? > > Where is the good place to do so? > Maybe somewhere here: > https://cmake.org/cmake/help/v3.4/variable/CMAKE_OSX_SYSROOT.html > > > > What do you think? > I'm thinking it'll be better to integrate that at the Modules/Platform/ level. For example, there is code in Darwin-Clang.cmake for the -mmacosx-version-min flag. Perhaps iOS can be toggled with CMAKE_GENERATOR_PLATFORM. Brad, what do you think? Or maybe toggled with CMAKE_OSX_SYSROOT, and if the SDK is pointing to another platform than OS X, we can switch between -mios-version-min= and -mmacosx-version-min= Clint > ? > > > ________________________________ > From: clinton at elemtech.com > Sent: Friday, December 11, 2015 8:21 PM > To: Bartosz Kosiorek > Cc: Bartosz Kosiorek; cmake-developers; Gregor Jasny > Subject: Re: [cmake-developers] Create subdirectories in Resource directory > for Frameworks and Application bundle. > > > ----- On Dec 11, 2015, at 11:44 AM, Bartosz Kosiorek > wrote: Hi > > Because there is difference between OS X and iOS Bundles directory structure > (see: Apple specification > https://developer.apple.com/library/mac/documentation/CoreFoundation/Concep > tual/CFBundles/BundleTypes/BundleTypes.html), in trunk (In CMake 3.5) > RESOURCE property create corresponding directory structure. I have already > fix that with: > https://public.kitware.com/Bug/view.php?id=15848 > Ok. I hadn't been following all your work. > Also, I didn't see a toggle in the CMake code you sent to choose an iOS > bundle instead of OS X bundles. How is that toggled? > So RESOURCE gives you a level of abstraction: > For OSX: > it will create "Resource" directory > > For iOS it will create "flat" directory structure. > > In your example "Resource" directory will be created in both cases (for OSX > and iOS). Which is wrong: > For OSX: it should create "Resource" directory > For iOS it will create "flat" directory structure. > > I could provide patch to fix that issue, if you agree with that. > What do you think about that? > Do you think the same should be applied to "Headers"? > > I think the abstraction seems reasonable, as well as what you are proposing. > However, I'm not an Apple guru. I wonder if there are other Apple experts > that can weigh in this if better feedback is needed. > Clint > > > Best Regards > Bartosz > > > > 2015-12-11 19:06 GMT+01:00 Clinton Stimpson > >: > > On Friday, December 11, 2015 05:01:41 PM Bartosz Kosiorek wrote: > > > Thanks Clint > > > > > > > > Unfortunately MACOSX_PACKAGE_LOCATION is not working correctly with > > RESOURCE property. For every resource which is marked as RESOURCE, will > > be placed in root "Resources" directory. > > > > > > > > The CMake code below create following directory structure for OS X: > > > > > > > > ?? mul.framework > > > > ??? Headers -> Versions/Current/Headers > > ??? Resources -> Versions/Current/Resources > > ??? Versions > > ? ??? A > > ? ? ??? Headers > > ? ? ? ??? mul.h > > ? ? ??? Modules > > ? ? ? ??? module.modulemap > > ? ? ??? Resources > > ? ? ? ??? Info.plist > > ? ? ? ??? mulres.txt > > ? ? ? ??? pl.txt > > ? ? ? ??? resourcefile.txt > > ? ? ??? lang > > ? ? ? ??? en.txt > > ? ? ??? mul > > ? ??? Current -> A > > ??? mul -> Versions/Current/mul > > > > > > > > > > As you can see eveything which is marked as "RESOURCE" will be placed in > > Versions/A/ directory My expectation will be that lang/pl.txt and > > lang/en.txt should be in Resources/lang/ directory. Here is complete > > directory structure: > > > > > > > > ?? mul.framework > > > > ??? Headers -> Versions/Current/Headers > > ??? Resources -> Versions/Current/Resources > > ??? Versions > > ? ??? A > > ? ? ??? Headers > > ? ? ? ??? mul.h > > ? ? ??? Modules > > ? ? ? ??? module.modulemap > > ? ? ??? Resources > > ? ? ? ??? Info.plist > > ? ? ? ??? mulres.txt > > ? ? ? ??? lang > > ? ? ? ? ??? pl.txt > > ? ? ? ? ??? en.txt > > ? ? ? ??? resourcefile.txt > > ? ? ??? lang > > ? ? ? ??? en.txt > > ? ? ??? mul > > ? ??? Current -> A > > ??? mul -> Versions/Current/mul > > > > > > > > > > What do you think about that? > > > > > > > > Here is the source code: > > > > > > > > set_property(SOURCE module.modulemap > > > > PROPERTY MACOSX_PACKAGE_LOCATION "Modules") > > > > > > > > set_property( > > > > SOURCE lang/en.txt lang/pl.txt > > PROPERTY MACOSX_PACKAGE_LOCATION "lang") > > > > > > > > set(RESLIST > > > > mulres.txt > > lang/pl.txt > > resourcefile.txt > > ) > > > > > > > > add_library(mul SHARED > > > > mul.c > > mul.h > > module.modulemap > > lang/pl.txt > > lang/en.txt > > resourcefile.txt > > mulres.txt) > > > > > > > > # Create an iOS Framework bundle > > set_target_properties(mul PROPERTIES > > > > FRAMEWORK TRUE > > MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul > > MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 > > MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 > > XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" > > PUBLIC_HEADER mul.h > > RESOURCE "${RESLIST}" > > > > ) > > > > Here is a CMakeLists.txt that will give you the desired layout. > I also see that MACOSX_PACKAGE_LOCATION doesn't work with RESOURCE. > > > set_property(SOURCE module.modulemap > PROPERTY MACOSX_PACKAGE_LOCATION "Modules") > > set_property( > SOURCE lang/pl.txt lang/en.txt > PROPERTY MACOSX_PACKAGE_LOCATION "Resources/lang") > > set(RESLIST > mulres.txt > resourcefile.txt > ) > > add_library(mul SHARED > mul.c > mul.h > module.modulemap > lang/pl.txt > lang/en.txt > resourcefile.txt > mulres.txt) > > # Create an iOS Framework bundle > set_target_properties(mul PROPERTIES > FRAMEWORK TRUE > MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul > MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 > MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 > XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" > PUBLIC_HEADER mul.h > RESOURCE "${RESLIST}" > ) > > > Now I'm wondering what does the RESOURCE target property do that > MACOSX_PACKAGE_LOCATION doesn't already support? > > Clint > -- > > 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 > From ben.boeckel at kitware.com Fri Dec 11 16:17:18 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 11 Dec 2015 16:17:18 -0500 Subject: [cmake-developers] set(CACHE) and the local scope In-Reply-To: <1483681.CMANjG64Xx@tuxedo.neundorf.net> References: <20151209223528.GA20586@megas.khq.kitware.com> <56698312.1070403@kitware.com> <20151211194439.GD26622@megas.khq.kitware.com> <1483681.CMANjG64Xx@tuxedo.neundorf.net> Message-ID: <20151211211718.GA9950@megas.khq.kitware.com> On Fri, Dec 11, 2015 at 22:13:46 +0100, Alexander Neundorf wrote: > On Friday, December 11, 2015 14:44:39 Ben Boeckel wrote: > ... > > Option 3: > > > > set(CACHE) (and any other cache-touching behavior) does *nothing* > > with the cache if a local variable by that name is defined > > just to clarify: and also does nothing to the local variable ? Correct. --Ben From mantis at public.kitware.com Fri Dec 11 16:56:50 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 11 Dec 2015 16:56:50 -0500 Subject: [cmake-developers] [CMake 0015879]: Wrong configuration name emitted by generator expression Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15879 ====================================================================== Reported By: Javier Martinez Assigned To: ====================================================================== Project: CMake Issue ID: 15879 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-12-11 16:56 EST Last Modified: 2015-12-11 16:56 EST ====================================================================== Summary: Wrong configuration name emitted by generator expression Description: CMake has issues with the $ and $ generator expressions when one configuration name is a substring of another. The attached reproducer has Debug, Release and ReleaseInternal as the configuration names. In this case ReleaseInternal is used instead of Release. Steps to Reproduce: - Generate solution (I placed the CMakeLists/txt file in the /bin folder and used cmake.exe . to generate the solution) - Open the generated solution Test.sln - Open the properties for TestProject -> CMake Rules ->stamp.txt.rule - Click on Configuration Properties -> Custom Build Tools -> General - On Configuration select Release - Inspect the Command Line property, it reads "Printing comment for ReleaseInternal" instead of "Printing comment for Release" Additional Information: Tested with CMake version cmake-3.4.1-win32-x86 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-12-11 16:56 Javier MartinezNew Issue 2015-12-11 16:56 Javier MartinezFile Added: CMakeLists.txt ====================================================================== From orion at cora.nwra.com Fri Dec 11 18:42:05 2015 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 11 Dec 2015 16:42:05 -0700 Subject: [cmake-developers] parallel install of different cmake versions Message-ID: <566B5F4D.1030701@cora.nwra.com> For Fedora EPEL we often end up packaging newer versions of cmake as cmakeXY (e.g. cmake34) that can be installed in parallel with the system cmake. This is a fairly invasive process. I'm attaching the current patch I'm working on for this. Is there any interest in cmake itself for supporting this kind of thing? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake34-cmake34.patch Type: text/x-patch Size: 24707 bytes Desc: not available URL: From Bartosz.Kosiorek at tomtom.com Fri Dec 11 19:26:11 2015 From: Bartosz.Kosiorek at tomtom.com (Bartosz Kosiorek) Date: Sat, 12 Dec 2015 00:26:11 +0000 Subject: [cmake-developers] [PATCH] Re: Create subdirectories in Resource directory for Frameworks and Application bundle. In-Reply-To: <2235818.ev9kN26Y2h@stryke> References: <1449759153039.51334@tomtom.com> <910432174.66323078.1449861684460.JavaMail.zimbra@elemtech.com> <1449866813173.56940@tomtom.com>,<2235818.ev9kN26Y2h@stryke> Message-ID: <1449879971168.34259@tomtom.com> Hi I have updated current documentation with examples, to reflect current status of CMake in OSX/iOS support. Such information is very useful for novice CMake developers, and it saves an hours of digging through mailing list and websites. Best Regards Bartosz ________________________________________ From: Clinton Stimpson Sent: Friday, December 11, 2015 10:16 PM To: Bartosz Kosiorek Cc: cmake-developers; Gregor Jasny Subject: Re: Create subdirectories in Resource directory for Frameworks and Application bundle. On Friday, December 11, 2015 08:46:56 PM Bartosz Kosiorek wrote: > Hi > > To enable iOS build, I'm using following settings in CMakeLists.txt: > > > set(APPLE_PLATFORM "iphonesimulator") > set(CMAKE_OSX_SYSROOT > "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platf > orm/Developer/SDKs/iPhoneSimulator.sdk") set(CMAKE_C_FLAGS "-isysroot > ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0") set(CMAKE_CXX_FLAGS "-isysroot > ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0") > Do you think it should be documented? > > Where is the good place to do so? > Maybe somewhere here: > https://cmake.org/cmake/help/v3.4/variable/CMAKE_OSX_SYSROOT.html > > > > What do you think? > I'm thinking it'll be better to integrate that at the Modules/Platform/ level. For example, there is code in Darwin-Clang.cmake for the -mmacosx-version-min flag. Perhaps iOS can be toggled with CMAKE_GENERATOR_PLATFORM. Brad, what do you think? Or maybe toggled with CMAKE_OSX_SYSROOT, and if the SDK is pointing to another platform than OS X, we can switch between -mios-version-min= and -mmacosx-version-min= Clint > ? > > > ________________________________ > From: clinton at elemtech.com > Sent: Friday, December 11, 2015 8:21 PM > To: Bartosz Kosiorek > Cc: Bartosz Kosiorek; cmake-developers; Gregor Jasny > Subject: Re: [cmake-developers] Create subdirectories in Resource directory > for Frameworks and Application bundle. > > > ----- On Dec 11, 2015, at 11:44 AM, Bartosz Kosiorek > wrote: Hi > > Because there is difference between OS X and iOS Bundles directory structure > (see: Apple specification > https://developer.apple.com/library/mac/documentation/CoreFoundation/Concep > tual/CFBundles/BundleTypes/BundleTypes.html), in trunk (In CMake 3.5) > RESOURCE property create corresponding directory structure. I have already > fix that with: > https://public.kitware.com/Bug/view.php?id=15848 > Ok. I hadn't been following all your work. > Also, I didn't see a toggle in the CMake code you sent to choose an iOS > bundle instead of OS X bundles. How is that toggled? > So RESOURCE gives you a level of abstraction: > For OSX: > it will create "Resource" directory > > For iOS it will create "flat" directory structure. > > In your example "Resource" directory will be created in both cases (for OSX > and iOS). Which is wrong: > For OSX: it should create "Resource" directory > For iOS it will create "flat" directory structure. > > I could provide patch to fix that issue, if you agree with that. > What do you think about that? > Do you think the same should be applied to "Headers"? > > I think the abstraction seems reasonable, as well as what you are proposing. > However, I'm not an Apple guru. I wonder if there are other Apple experts > that can weigh in this if better feedback is needed. > Clint > > > Best Regards > Bartosz > > > > 2015-12-11 19:06 GMT+01:00 Clinton Stimpson > >: > > On Friday, December 11, 2015 05:01:41 PM Bartosz Kosiorek wrote: > > > Thanks Clint > > > > > > > > Unfortunately MACOSX_PACKAGE_LOCATION is not working correctly with > > RESOURCE property. For every resource which is marked as RESOURCE, will > > be placed in root "Resources" directory. > > > > > > > > The CMake code below create following directory structure for OS X: > > > > > > > > ?? mul.framework > > > > ??? Headers -> Versions/Current/Headers > > ??? Resources -> Versions/Current/Resources > > ??? Versions > > ? ??? A > > ? ? ??? Headers > > ? ? ? ??? mul.h > > ? ? ??? Modules > > ? ? ? ??? module.modulemap > > ? ? ??? Resources > > ? ? ? ??? Info.plist > > ? ? ? ??? mulres.txt > > ? ? ? ??? pl.txt > > ? ? ? ??? resourcefile.txt > > ? ? ??? lang > > ? ? ? ??? en.txt > > ? ? ??? mul > > ? ??? Current -> A > > ??? mul -> Versions/Current/mul > > > > > > > > > > As you can see eveything which is marked as "RESOURCE" will be placed in > > Versions/A/ directory My expectation will be that lang/pl.txt and > > lang/en.txt should be in Resources/lang/ directory. Here is complete > > directory structure: > > > > > > > > ?? mul.framework > > > > ??? Headers -> Versions/Current/Headers > > ??? Resources -> Versions/Current/Resources > > ??? Versions > > ? ??? A > > ? ? ??? Headers > > ? ? ? ??? mul.h > > ? ? ??? Modules > > ? ? ? ??? module.modulemap > > ? ? ??? Resources > > ? ? ? ??? Info.plist > > ? ? ? ??? mulres.txt > > ? ? ? ??? lang > > ? ? ? ? ??? pl.txt > > ? ? ? ? ??? en.txt > > ? ? ? ??? resourcefile.txt > > ? ? ??? lang > > ? ? ? ??? en.txt > > ? ? ??? mul > > ? ??? Current -> A > > ??? mul -> Versions/Current/mul > > > > > > > > > > What do you think about that? > > > > > > > > Here is the source code: > > > > > > > > set_property(SOURCE module.modulemap > > > > PROPERTY MACOSX_PACKAGE_LOCATION "Modules") > > > > > > > > set_property( > > > > SOURCE lang/en.txt lang/pl.txt > > PROPERTY MACOSX_PACKAGE_LOCATION "lang") > > > > > > > > set(RESLIST > > > > mulres.txt > > lang/pl.txt > > resourcefile.txt > > ) > > > > > > > > add_library(mul SHARED > > > > mul.c > > mul.h > > module.modulemap > > lang/pl.txt > > lang/en.txt > > resourcefile.txt > > mulres.txt) > > > > > > > > # Create an iOS Framework bundle > > set_target_properties(mul PROPERTIES > > > > FRAMEWORK TRUE > > MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul > > MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 > > MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 > > XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" > > PUBLIC_HEADER mul.h > > RESOURCE "${RESLIST}" > > > > ) > > > > Here is a CMakeLists.txt that will give you the desired layout. > I also see that MACOSX_PACKAGE_LOCATION doesn't work with RESOURCE. > > > set_property(SOURCE module.modulemap > PROPERTY MACOSX_PACKAGE_LOCATION "Modules") > > set_property( > SOURCE lang/pl.txt lang/en.txt > PROPERTY MACOSX_PACKAGE_LOCATION "Resources/lang") > > set(RESLIST > mulres.txt > resourcefile.txt > ) > > add_library(mul SHARED > mul.c > mul.h > module.modulemap > lang/pl.txt > lang/en.txt > resourcefile.txt > mulres.txt) > > # Create an iOS Framework bundle > set_target_properties(mul PROPERTIES > FRAMEWORK TRUE > MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul > MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 > MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 > XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" > PUBLIC_HEADER mul.h > RESOURCE "${RESLIST}" > ) > > > Now I'm wondering what does the RESOURCE target property do that > MACOSX_PACKAGE_LOCATION doesn't already support? > > Clint > -- > > 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 > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-examples-of-usage-for-MACOSX_PACKAGE_LOCATION-CM.patch Type: application/octet-stream Size: 6173 bytes Desc: 0001-Add-examples-of-usage-for-MACOSX_PACKAGE_LOCATION-CM.patch URL: From ruslan_baratov at yahoo.com Fri Dec 11 19:58:19 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Sat, 12 Dec 2015 07:58:19 +0700 Subject: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle. In-Reply-To: <1449866813173.56940@tomtom.com> References: <1449759153039.51334@tomtom.com> <1813369686.65723125.1449847446080.JavaMail.zimbra@elemtech.com> <1449853301422.90915@tomtom.com> <2780526.IlfGfMxfeF@stryke> <910432174.66323078.1449861684460.JavaMail.zimbra@elemtech.com> <1449866813173.56940@tomtom.com> Message-ID: <566B712B.6060503@yahoo.com> On 12-Dec-15 03:46, Bartosz Kosiorek wrote: > > Hi > > To enable iOS build, I'm using following settings in CMakeLists.txt: > > > set(APPLE_PLATFORM "iphonesimulator") I think this one not needed. Can't find any place where it parsed. > set(CMAKE_OSX_SYSROOT > "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk") Can be set to: set(CMAKE_OSX_SYSROOT "iphoneos") in this case will support both simulator and device > set(CMAKE_C_FLAGS "-isysroot ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0") > set(CMAKE_CXX_FLAGS "-isysroot ${CMAKE_OSX_SYSROOT} > -mios-version-min=7.0") You can set minimum version by CMAKE_XCODE_ATTRIBUTE_IPHONEOS_DEPLOYMENT_TARGET variable. In case of `CMAKE_OSX_SYSROOT` variable is set to `iphoneos` option `-isysroot` is redundant. > > Do you think it should be documented? > > Where is the good place to do so? > Maybe somewhere here: > https://cmake.org/cmake/help/v3.4/variable/CMAKE_OSX_SYSROOT.html > > > What do you think? > > ? > > > ------------------------------------------------------------------------ > *From:* clinton at elemtech.com > *Sent:* Friday, December 11, 2015 8:21 PM > *To:* Bartosz Kosiorek > *Cc:* Bartosz Kosiorek; cmake-developers; Gregor Jasny > *Subject:* Re: [cmake-developers] Create subdirectories in Resource > directory for Frameworks and Application bundle. > > > > ----- On Dec 11, 2015, at 11:44 AM, Bartosz Kosiorek > wrote: > > Hi > > Because there is difference between OS X and iOS Bundles directory > structure (see: Apple specification > https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html), > > in trunk (In CMake 3.5) RESOURCE property create corresponding > directory structure. > I have already fix that with: > https://public.kitware.com/Bug/view.php?id=15848 > > Ok. I hadn't been following all your work. > Also, I didn't see a toggle in the CMake code you sent to choose an > iOS bundle instead of OS X bundles. How is that toggled? > > So RESOURCE gives you a level of abstraction: > For OSX: > it will create "Resource" directory > > For iOS it will create "flat" directory structure. > > In your example "Resource" directory will be created in both cases > (for OSX and iOS). > Which is wrong: > For OSX: it should create "Resource" directory > For iOS it will create "flat" directory structure. > > I could provide patch to fix that issue, if you agree with that. > What do you think about that? > Do you think the same should be applied to "Headers"? > > > I think the abstraction seems reasonable, as well as what you are > proposing. However, I'm not an Apple guru. > I wonder if there are other Apple experts that can weigh in this if > better feedback is needed. > > Clint > > > > Best Regards > Bartosz > > > > 2015-12-11 19:06 GMT+01:00 Clinton Stimpson >: > > > > On Friday, December 11, 2015 05:01:41 PM Bartosz Kosiorek wrote: > > Thanks Clint > > > > Unfortunately MACOSX_PACKAGE_LOCATION is not working > correctly with RESOURCE > > property. For every resource which is marked as RESOURCE, > will be placed in > > root "Resources" directory. > > > > The CMake code below create following directory structure > for OS X: > > > > ?? mul.framework > > ??? Headers -> Versions/Current/Headers > > ??? Resources -> Versions/Current/Resources > > ??? Versions > > ? ??? A > > ? ? ??? Headers > > ? ? ? ??? mul.h > > ? ? ??? Modules > > ? ? ? ??? module.modulemap > > ? ? ??? Resources > > ? ? ? ??? Info.plist > > ? ? ? ??? mulres.txt > > ? ? ? ??? pl.txt > > ? ? ? ??? resourcefile.txt > > ? ? ??? lang > > ? ? ? ??? en.txt > > ? ? ??? mul > > ? ??? Current -> A > > ??? mul -> Versions/Current/mul > > > > > > As you can see eveything which is marked as "RESOURCE" will > be placed in > > Versions/A/ directory My expectation will be that > lang/pl.txt and > > lang/en.txt should be in Resources/lang/ directory. Here is > complete > > directory structure: > > > > ?? mul.framework > > ??? Headers -> Versions/Current/Headers > > ??? Resources -> Versions/Current/Resources > > ??? Versions > > ? ??? A > > ? ? ??? Headers > > ? ? ? ??? mul.h > > ? ? ??? Modules > > ? ? ? ??? module.modulemap > > ? ? ??? Resources > > ? ? ? ??? Info.plist > > ? ? ? ??? mulres.txt > > ? ? ? ??? lang > > ? ? ? ? ??? pl.txt > > ? ? ? ? ??? en.txt > > ? ? ? ??? resourcefile.txt > > ? ? ??? lang > > ? ? ? ??? en.txt > > ? ? ??? mul > > ? ??? Current -> A > > ??? mul -> Versions/Current/mul > > > > > > What do you think about that? > > > > Here is the source code: > > > > set_property(SOURCE module.modulemap > > PROPERTY MACOSX_PACKAGE_LOCATION "Modules") > > > > set_property( > > SOURCE lang/en.txt lang/pl.txt > > PROPERTY MACOSX_PACKAGE_LOCATION "lang") > > > > set(RESLIST > > mulres.txt > > lang/pl.txt > > resourcefile.txt > > ) > > > > add_library(mul SHARED > > mul.c > > mul.h > > module.modulemap > > lang/pl.txt > > lang/en.txt > > resourcefile.txt > > mulres.txt) > > > > # Create an iOS Framework bundle > > set_target_properties(mul PROPERTIES > > FRAMEWORK TRUE > > MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul > > MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 > > MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 > > XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" > > PUBLIC_HEADER mul.h > > RESOURCE "${RESLIST}" > > ) > > > Here is a CMakeLists.txt that will give you the desired layout. > I also see that MACOSX_PACKAGE_LOCATION doesn't work with > RESOURCE. > > > set_property(SOURCE module.modulemap > PROPERTY MACOSX_PACKAGE_LOCATION "Modules") > > set_property( > SOURCE lang/pl.txt lang/en.txt > PROPERTY MACOSX_PACKAGE_LOCATION "Resources/lang") > > set(RESLIST > mulres.txt > resourcefile.txt > ) > > add_library(mul SHARED > mul.c > mul.h > module.modulemap > lang/pl.txt > lang/en.txt > resourcefile.txt > mulres.txt) > > # Create an iOS Framework bundle > set_target_properties(mul PROPERTIES > FRAMEWORK TRUE > MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul > MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 > MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 > XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" > PUBLIC_HEADER mul.h > RESOURCE "${RESLIST}" > ) > > > Now I'm wondering what does the RESOURCE target property do that > MACOSX_PACKAGE_LOCATION doesn't already support? > > Clint > -- > > 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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruslan_baratov at yahoo.com Fri Dec 11 20:15:58 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Sat, 12 Dec 2015 08:15:58 +0700 Subject: [cmake-developers] [PATCH] Re: Create subdirectories in Resource directory for Frameworks and Application bundle. In-Reply-To: <1449879971168.34259@tomtom.com> References: <1449759153039.51334@tomtom.com> <910432174.66323078.1449861684460.JavaMail.zimbra@elemtech.com> <1449866813173.56940@tomtom.com> <2235818.ev9kN26Y2h@stryke> <1449879971168.34259@tomtom.com> Message-ID: <566B754E.5050509@yahoo.com> On 12-Dec-15 07:26, Bartosz Kosiorek wrote: > Hi > I have updated current documentation with examples, to reflect current status of CMake in OSX/iOS support. > > Such information is very useful for novice CMake developers, > and it saves an hours of digging through mailing list and websites. This is true, totally agree. +If user would like to build for iPhone device, it could specify:: + + set(CMAKE_OSX_ARCHITECTURES "armv7;armv7s;arm64") Note that: * you can mix simulator and device architectures here * if more than one architecture set then `ONLY_ACTIVE_ARCH` will be set to `NO`. it is useful for install/archive stage but will slow down your development process. at least it worth to mention CMAKE_XCODE_ATTRIBUTE_ONLY_ACTIVE_ARCH variable usage * I think newly created IOS_INSTALL_COMBINED should be mentioned too * also architectures can be set using next Xcode attributes: set_target_properties( foo PROPERTIES XCODE_ATTRIBUTE_ARCHS[sdk=iphoneos*] armv7 XCODE_ATTRIBUTE_VALID_ARCHS[sdk=iphoneos*] armv7 XCODE_ATTRIBUTE_ARCHS[sdk=iphonesimulator*] x86_64 XCODE_ATTRIBUTE_VALID_ARCHS[sdk=iphonesimulator*] x86_64 ) note that to specify several architectures you need to use space as a separator (unlike CMake list): set_target_properties( foo PROPERTIES XCODE_ATTRIBUTE_ARCHS[sdk=iphoneos*] "armv7 arm64" XCODE_ATTRIBUTE_VALID_ARCHS[sdk=iphoneos*] "armv7 arm64" ) Ruslan > > Best Regards > Bartosz > > > ________________________________________ > From: Clinton Stimpson > Sent: Friday, December 11, 2015 10:16 PM > To: Bartosz Kosiorek > Cc: cmake-developers; Gregor Jasny > Subject: Re: Create subdirectories in Resource directory for Frameworks and Application bundle. > > On Friday, December 11, 2015 08:46:56 PM Bartosz Kosiorek wrote: >> Hi >> >> To enable iOS build, I'm using following settings in CMakeLists.txt: >> >> >> set(APPLE_PLATFORM "iphonesimulator") >> set(CMAKE_OSX_SYSROOT >> "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platf >> orm/Developer/SDKs/iPhoneSimulator.sdk") > set(CMAKE_C_FLAGS "-isysroot >> ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0") set(CMAKE_CXX_FLAGS "-isysroot >> ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0") >> Do you think it should be documented? >> >> Where is the good place to do so? >> Maybe somewhere here: >> https://cmake.org/cmake/help/v3.4/variable/CMAKE_OSX_SYSROOT.html >> >> >> >> What do you think? >> > I'm thinking it'll be better to integrate that at the Modules/Platform/ level. > For example, there is code in Darwin-Clang.cmake for the -mmacosx-version-min > flag. > > Perhaps iOS can be toggled with CMAKE_GENERATOR_PLATFORM. > Brad, what do you think? > > Or maybe toggled with CMAKE_OSX_SYSROOT, and if the SDK is pointing to another > platform than OS X, we can switch between > -mios-version-min= and -mmacosx-version-min= > > Clint > > >> ? >> >> >> ________________________________ >> From: clinton at elemtech.com >> Sent: Friday, December 11, 2015 8:21 PM >> To: Bartosz Kosiorek >> Cc: Bartosz Kosiorek; cmake-developers; Gregor Jasny >> Subject: Re: [cmake-developers] Create subdirectories in Resource directory >> for Frameworks and Application bundle. >> >> ----- On Dec 11, 2015, at 11:44 AM, Bartosz Kosiorek >> wrote: > Hi >> Because there is difference between OS X and iOS Bundles directory structure >> (see: Apple specification >> https://developer.apple.com/library/mac/documentation/CoreFoundation/Concep >> tual/CFBundles/BundleTypes/BundleTypes.html), in trunk (In CMake 3.5) >> RESOURCE property create corresponding directory structure. I have already >> fix that with: >> https://public.kitware.com/Bug/view.php?id=15848 >> Ok. I hadn't been following all your work. >> Also, I didn't see a toggle in the CMake code you sent to choose an iOS >> bundle instead of OS X bundles. How is that toggled? >> So RESOURCE gives you a level of abstraction: >> For OSX: >> it will create "Resource" directory >> >> For iOS it will create "flat" directory structure. >> >> In your example "Resource" directory will be created in both cases (for OSX >> and iOS). > Which is wrong: >> For OSX: it should create "Resource" directory >> For iOS it will create "flat" directory structure. >> >> I could provide patch to fix that issue, if you agree with that. >> What do you think about that? >> Do you think the same should be applied to "Headers"? >> >> I think the abstraction seems reasonable, as well as what you are proposing. >> However, I'm not an Apple guru. > I wonder if there are other Apple experts >> that can weigh in this if better feedback is needed. >> Clint >> >> >> Best Regards >> Bartosz >> >> >> >> 2015-12-11 19:06 GMT+01:00 Clinton Stimpson >> >: >> On Friday, December 11, 2015 05:01:41 PM Bartosz Kosiorek wrote: >> >>> Thanks Clint >>> >>> >>> >>> Unfortunately MACOSX_PACKAGE_LOCATION is not working correctly with >>> RESOURCE > property. For every resource which is marked as RESOURCE, will >>> be placed in root "Resources" directory. >>> >>> >>> >>> The CMake code below create following directory structure for OS X: >>> >>> >>> >>> ?? mul.framework >>> >>> ??? Headers -> Versions/Current/Headers >>> ??? Resources -> Versions/Current/Resources >>> ??? Versions >>> ? ??? A >>> ? ? ??? Headers >>> ? ? ? ??? mul.h >>> ? ? ??? Modules >>> ? ? ? ??? module.modulemap >>> ? ? ??? Resources >>> ? ? ? ??? Info.plist >>> ? ? ? ??? mulres.txt >>> ? ? ? ??? pl.txt >>> ? ? ? ??? resourcefile.txt >>> ? ? ??? lang >>> ? ? ? ??? en.txt >>> ? ? ??? mul >>> ? ??? Current -> A >>> ??? mul -> Versions/Current/mul >>> >>> >>> >>> >>> As you can see eveything which is marked as "RESOURCE" will be placed in >>> Versions/A/ directory My expectation will be that lang/pl.txt and >>> lang/en.txt should be in Resources/lang/ directory. Here is complete >>> directory structure: >>> >>> >>> >>> ?? mul.framework >>> >>> ??? Headers -> Versions/Current/Headers >>> ??? Resources -> Versions/Current/Resources >>> ??? Versions >>> ? ??? A >>> ? ? ??? Headers >>> ? ? ? ??? mul.h >>> ? ? ??? Modules >>> ? ? ? ??? module.modulemap >>> ? ? ??? Resources >>> ? ? ? ??? Info.plist >>> ? ? ? ??? mulres.txt >>> ? ? ? ??? lang >>> ? ? ? ? ??? pl.txt >>> ? ? ? ? ??? en.txt >>> ? ? ? ??? resourcefile.txt >>> ? ? ??? lang >>> ? ? ? ??? en.txt >>> ? ? ??? mul >>> ? ??? Current -> A >>> ??? mul -> Versions/Current/mul >>> >>> >>> >>> >>> What do you think about that? >>> >>> >>> >>> Here is the source code: >>> >>> >>> >>> set_property(SOURCE module.modulemap >>> >>> PROPERTY MACOSX_PACKAGE_LOCATION "Modules") >>> >>> >>> >>> set_property( >>> >>> SOURCE lang/en.txt lang/pl.txt >>> PROPERTY MACOSX_PACKAGE_LOCATION "lang") >>> >>> >>> >>> set(RESLIST >>> >>> mulres.txt >>> lang/pl.txt >>> resourcefile.txt >>> ) >>> >>> >>> >>> add_library(mul SHARED >>> >>> mul.c >>> mul.h >>> module.modulemap >>> lang/pl.txt >>> lang/en.txt >>> resourcefile.txt >>> mulres.txt) >>> >>> >>> >>> # Create an iOS Framework bundle >>> set_target_properties(mul PROPERTIES >>> >>> FRAMEWORK TRUE >>> MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul >>> MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 >>> MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 >>> XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" >>> PUBLIC_HEADER mul.h >>> RESOURCE "${RESLIST}" >>> >>> ) >> >> >> Here is a CMakeLists.txt that will give you the desired layout. >> I also see that MACOSX_PACKAGE_LOCATION doesn't work with RESOURCE. >> >> >> set_property(SOURCE module.modulemap >> PROPERTY MACOSX_PACKAGE_LOCATION "Modules") >> >> set_property( >> SOURCE lang/pl.txt lang/en.txt >> PROPERTY MACOSX_PACKAGE_LOCATION "Resources/lang") >> >> set(RESLIST >> mulres.txt >> resourcefile.txt >> ) >> >> add_library(mul SHARED >> mul.c >> mul.h >> module.modulemap >> lang/pl.txt >> lang/en.txt >> resourcefile.txt >> mulres.txt) >> >> # Create an iOS Framework bundle >> set_target_properties(mul PROPERTIES >> FRAMEWORK TRUE >> MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul >> MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 >> MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 >> XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" >> PUBLIC_HEADER mul.h >> RESOURCE "${RESLIST}" >> ) >> >> >> Now I'm wondering what does the RESOURCE target property do that >> MACOSX_PACKAGE_LOCATION doesn't already support? >> >> Clint >> -- >> >> 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bartosz.Kosiorek at tomtom.com Fri Dec 11 22:08:29 2015 From: Bartosz.Kosiorek at tomtom.com (Bartosz Kosiorek) Date: Sat, 12 Dec 2015 03:08:29 +0000 Subject: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle. In-Reply-To: <566B712B.6060503@yahoo.com> References: <1449759153039.51334@tomtom.com> <1813369686.65723125.1449847446080.JavaMail.zimbra@elemtech.com> <1449853301422.90915@tomtom.com> <2780526.IlfGfMxfeF@stryke> <910432174.66323078.1449861684460.JavaMail.zimbra@elemtech.com> <1449866813173.56940@tomtom.com>,<566B712B.6060503@yahoo.com> Message-ID: <1449889708273.6810@tomtom.com> Thanks Ruslan. I would like to create instruction which is universal for all generators. Currently we would like to support both Make/Ninja and Xcode generators, because Make is much faster than Xcode generator, and we are using it in our CI system. Make is also common for other architectures (Linux, QNX, Android etc.) Unfortunately set(CMAKE_OSX_SYSROOT "iphoneos") is not working for me. It displays error: /Users/warsaw/Perforce/cmake-dev/cmake-build/bin/cmake .. && /Users/warsaw/Perforce/cmake-dev/cmake-build/bin/cmake --build . -- Configuring done -- Generating done -- Build files have been written to: /Users/warsaw/Perforce/cmake_ios_framework_with_resource2/builddir [ 14%] Building C object shared_empty/heymath/CMakeFiles/heymath.dir/add.c.o clang: warning: no such sysroot directory: 'iphoneos' ... Do you have some tip for that? After removing "-isysroot ${CMAKE_OSX_SYSROOT}" everything works perfectly. Thanks Unfortunately CMAKE_XCODE_ATTRIBUTE_IPHONEOS_DEPLOYMENT_TARGET is not working with Make. Is it possible to introduce CMAKE_IOS_DEPLOYMENT_TARGET, as we already have CMAKE_OSX_DEPLOYMENT_TARGET? I have attached my example script which I'm using. ?Could you please modify it to be better (and still support other generators)? Best Regards Bartosz ________________________________ From: Ruslan Baratov Sent: Saturday, December 12, 2015 1:58 AM To: Bartosz Kosiorek Cc: clinton at elemtech.com; Gregor Jasny; CMake Developers Subject: Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle. On 12-Dec-15 03:46, Bartosz Kosiorek wrote: Hi To enable iOS build, I'm using following settings in CMakeLists.txt: set(APPLE_PLATFORM "iphonesimulator") I think this one not needed. Can't find any place where it parsed. set(CMAKE_OSX_SYSROOT "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk") Can be set to: set(CMAKE_OSX_SYSROOT "iphoneos") in this case will support both simulator and device set(CMAKE_C_FLAGS "-isysroot ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0") set(CMAKE_CXX_FLAGS "-isysroot ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0") You can set minimum version by CMAKE_XCODE_ATTRIBUTE_IPHONEOS_DEPLOYMENT_TARGET variable. In case of `CMAKE_OSX_SYSROOT` variable is set to `iphoneos` option `-isysroot` is redundant. Do you think it should be documented? Where is the good place to do so? Maybe somewhere here: https://cmake.org/cmake/help/v3.4/variable/CMAKE_OSX_SYSROOT.html What do you think? ? ________________________________ From: clinton at elemtech.com Sent: Friday, December 11, 2015 8:21 PM To: Bartosz Kosiorek Cc: Bartosz Kosiorek; cmake-developers; Gregor Jasny Subject: Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle. ----- On Dec 11, 2015, at 11:44 AM, Bartosz Kosiorek wrote: Hi Because there is difference between OS X and iOS Bundles directory structure (see: Apple specification https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html), in trunk (In CMake 3.5) RESOURCE property create corresponding directory structure. I have already fix that with: https://public.kitware.com/Bug/view.php?id=15848 Ok. I hadn't been following all your work. Also, I didn't see a toggle in the CMake code you sent to choose an iOS bundle instead of OS X bundles. How is that toggled? So RESOURCE gives you a level of abstraction: For OSX: it will create "Resource" directory For iOS it will create "flat" directory structure. In your example "Resource" directory will be created in both cases (for OSX and iOS). Which is wrong: For OSX: it should create "Resource" directory For iOS it will create "flat" directory structure. I could provide patch to fix that issue, if you agree with that. What do you think about that? Do you think the same should be applied to "Headers"? I think the abstraction seems reasonable, as well as what you are proposing. However, I'm not an Apple guru. I wonder if there are other Apple experts that can weigh in this if better feedback is needed. Clint Best Regards Bartosz 2015-12-11 19:06 GMT+01:00 Clinton Stimpson >: On Friday, December 11, 2015 05:01:41 PM Bartosz Kosiorek wrote: > Thanks Clint > > Unfortunately MACOSX_PACKAGE_LOCATION is not working correctly with RESOURCE > property. For every resource which is marked as RESOURCE, will be placed in > root "Resources" directory. > > The CMake code below create following directory structure for OS X: > > ?? mul.framework > ??? Headers -> Versions/Current/Headers > ??? Resources -> Versions/Current/Resources > ??? Versions > ? ??? A > ? ? ??? Headers > ? ? ? ??? mul.h > ? ? ??? Modules > ? ? ? ??? module.modulemap > ? ? ??? Resources > ? ? ? ??? Info.plist > ? ? ? ??? mulres.txt > ? ? ? ??? pl.txt > ? ? ? ??? resourcefile.txt > ? ? ??? lang > ? ? ? ??? en.txt > ? ? ??? mul > ? ??? Current -> A > ??? mul -> Versions/Current/mul > > > As you can see eveything which is marked as "RESOURCE" will be placed in > Versions/A/ directory My expectation will be that lang/pl.txt and > lang/en.txt should be in Resources/lang/ directory. Here is complete > directory structure: > > ?? mul.framework > ??? Headers -> Versions/Current/Headers > ??? Resources -> Versions/Current/Resources > ??? Versions > ? ??? A > ? ? ??? Headers > ? ? ? ??? mul.h > ? ? ??? Modules > ? ? ? ??? module.modulemap > ? ? ??? Resources > ? ? ? ??? Info.plist > ? ? ? ??? mulres.txt > ? ? ? ??? lang > ? ? ? ? ??? pl.txt > ? ? ? ? ??? en.txt > ? ? ? ??? resourcefile.txt > ? ? ??? lang > ? ? ? ??? en.txt > ? ? ??? mul > ? ??? Current -> A > ??? mul -> Versions/Current/mul > > > What do you think about that? > > Here is the source code: > > set_property(SOURCE module.modulemap > PROPERTY MACOSX_PACKAGE_LOCATION "Modules") > > set_property( > SOURCE lang/en.txt lang/pl.txt > PROPERTY MACOSX_PACKAGE_LOCATION "lang") > > set(RESLIST > mulres.txt > lang/pl.txt > resourcefile.txt > ) > > add_library(mul SHARED > mul.c > mul.h > module.modulemap > lang/pl.txt > lang/en.txt > resourcefile.txt > mulres.txt) > > # Create an iOS Framework bundle > set_target_properties(mul PROPERTIES > FRAMEWORK TRUE > MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul > MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 > MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 > XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" > PUBLIC_HEADER mul.h > RESOURCE "${RESLIST}" > ) Here is a CMakeLists.txt that will give you the desired layout. I also see that MACOSX_PACKAGE_LOCATION doesn't work with RESOURCE. set_property(SOURCE module.modulemap PROPERTY MACOSX_PACKAGE_LOCATION "Modules") set_property( SOURCE lang/pl.txt lang/en.txt PROPERTY MACOSX_PACKAGE_LOCATION "Resources/lang") set(RESLIST mulres.txt resourcefile.txt ) add_library(mul SHARED mul.c mul.h module.modulemap lang/pl.txt lang/en.txt resourcefile.txt mulres.txt) # Create an iOS Framework bundle set_target_properties(mul PROPERTIES FRAMEWORK TRUE MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" PUBLIC_HEADER mul.h RESOURCE "${RESLIST}" ) Now I'm wondering what does the RESOURCE target property do that MACOSX_PACKAGE_LOCATION doesn't already support? Clint -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake_ios_framework_with_resource2.zip Type: application/zip Size: 81233 bytes Desc: cmake_ios_framework_with_resource2.zip URL: From Bartosz.Kosiorek at tomtom.com Fri Dec 11 22:12:34 2015 From: Bartosz.Kosiorek at tomtom.com (Bartosz Kosiorek) Date: Sat, 12 Dec 2015 03:12:34 +0000 Subject: [cmake-developers] [PATCH] Re: Create subdirectories in Resource directory for Frameworks and Application bundle. In-Reply-To: <566B754E.5050509@yahoo.com> References: <1449759153039.51334@tomtom.com> <910432174.66323078.1449861684460.JavaMail.zimbra@elemtech.com> <1449866813173.56940@tomtom.com> <2235818.ev9kN26Y2h@stryke> <1449879971168.34259@tomtom.com>,<566B754E.5050509@yahoo.com> Message-ID: <1449889954743.42940@tomtom.com> Thanks Ruslan. I will update documentation with information about such option (for Xcode generator) Is it possible to mix arm and x86 architectures also for Make generator? I'm very interesting in that bit :-) Best Regards Bartosz ________________________________ From: Ruslan Baratov Sent: Saturday, December 12, 2015 2:15 AM To: Bartosz Kosiorek Cc: Clinton Stimpson; cmake-developers; Gregor Jasny Subject: Re: [cmake-developers] [PATCH] Re: Create subdirectories in Resource directory for Frameworks and Application bundle. On 12-Dec-15 07:26, Bartosz Kosiorek wrote: Hi I have updated current documentation with examples, to reflect current status of CMake in OSX/iOS support. Such information is very useful for novice CMake developers, and it saves an hours of digging through mailing list and websites. This is true, totally agree. +If user would like to build for iPhone device, it could specify:: + + set(CMAKE_OSX_ARCHITECTURES "armv7;armv7s;arm64") Note that: * you can mix simulator and device architectures here * if more than one architecture set then `ONLY_ACTIVE_ARCH` will be set to `NO`. it is useful for install/archive stage but will slow down your development process. at least it worth to mention CMAKE_XCODE_ATTRIBUTE_ONLY_ACTIVE_ARCH variable usage * I think newly created IOS_INSTALL_COMBINED should be mentioned too * also architectures can be set using next Xcode attributes: set_target_properties( foo PROPERTIES XCODE_ATTRIBUTE_ARCHS[sdk=iphoneos*] armv7 XCODE_ATTRIBUTE_VALID_ARCHS[sdk=iphoneos*] armv7 XCODE_ATTRIBUTE_ARCHS[sdk=iphonesimulator*] x86_64 XCODE_ATTRIBUTE_VALID_ARCHS[sdk=iphonesimulator*] x86_64 ) note that to specify several architectures you need to use space as a separator (unlike CMake list): set_target_properties( foo PROPERTIES XCODE_ATTRIBUTE_ARCHS[sdk=iphoneos*] "armv7 arm64" XCODE_ATTRIBUTE_VALID_ARCHS[sdk=iphoneos*] "armv7 arm64" ) Ruslan Best Regards Bartosz ________________________________________ From: Clinton Stimpson Sent: Friday, December 11, 2015 10:16 PM To: Bartosz Kosiorek Cc: cmake-developers; Gregor Jasny Subject: Re: Create subdirectories in Resource directory for Frameworks and Application bundle. On Friday, December 11, 2015 08:46:56 PM Bartosz Kosiorek wrote: Hi To enable iOS build, I'm using following settings in CMakeLists.txt: set(APPLE_PLATFORM "iphonesimulator") set(CMAKE_OSX_SYSROOT "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platf orm/Developer/SDKs/iPhoneSimulator.sdk") set(CMAKE_C_FLAGS "-isysroot ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0") set(CMAKE_CXX_FLAGS "-isysroot ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0") Do you think it should be documented? Where is the good place to do so? Maybe somewhere here: https://cmake.org/cmake/help/v3.4/variable/CMAKE_OSX_SYSROOT.html What do you think? I'm thinking it'll be better to integrate that at the Modules/Platform/ level. For example, there is code in Darwin-Clang.cmake for the -mmacosx-version-min flag. Perhaps iOS can be toggled with CMAKE_GENERATOR_PLATFORM. Brad, what do you think? Or maybe toggled with CMAKE_OSX_SYSROOT, and if the SDK is pointing to another platform than OS X, we can switch between -mios-version-min= and -mmacosx-version-min= Clint ? ________________________________ From: clinton at elemtech.com Sent: Friday, December 11, 2015 8:21 PM To: Bartosz Kosiorek Cc: Bartosz Kosiorek; cmake-developers; Gregor Jasny Subject: Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle. ----- On Dec 11, 2015, at 11:44 AM, Bartosz Kosiorek wrote: Hi Because there is difference between OS X and iOS Bundles directory structure (see: Apple specification https://developer.apple.com/library/mac/documentation/CoreFoundation/Concep tual/CFBundles/BundleTypes/BundleTypes.html), in trunk (In CMake 3.5) RESOURCE property create corresponding directory structure. I have already fix that with: https://public.kitware.com/Bug/view.php?id=15848 Ok. I hadn't been following all your work. Also, I didn't see a toggle in the CMake code you sent to choose an iOS bundle instead of OS X bundles. How is that toggled? So RESOURCE gives you a level of abstraction: For OSX: it will create "Resource" directory For iOS it will create "flat" directory structure. In your example "Resource" directory will be created in both cases (for OSX and iOS). Which is wrong: For OSX: it should create "Resource" directory For iOS it will create "flat" directory structure. I could provide patch to fix that issue, if you agree with that. What do you think about that? Do you think the same should be applied to "Headers"? I think the abstraction seems reasonable, as well as what you are proposing. However, I'm not an Apple guru. I wonder if there are other Apple experts that can weigh in this if better feedback is needed. Clint Best Regards Bartosz 2015-12-11 19:06 GMT+01:00 Clinton Stimpson >: On Friday, December 11, 2015 05:01:41 PM Bartosz Kosiorek wrote: Thanks Clint Unfortunately MACOSX_PACKAGE_LOCATION is not working correctly with RESOURCE property. For every resource which is marked as RESOURCE, will be placed in root "Resources" directory. The CMake code below create following directory structure for OS X: ?? mul.framework ??? Headers -> Versions/Current/Headers ??? Resources -> Versions/Current/Resources ??? Versions ? ??? A ? ? ??? Headers ? ? ? ??? mul.h ? ? ??? Modules ? ? ? ??? module.modulemap ? ? ??? Resources ? ? ? ??? Info.plist ? ? ? ??? mulres.txt ? ? ? ??? pl.txt ? ? ? ??? resourcefile.txt ? ? ??? lang ? ? ? ??? en.txt ? ? ??? mul ? ??? Current -> A ??? mul -> Versions/Current/mul As you can see eveything which is marked as "RESOURCE" will be placed in Versions/A/ directory My expectation will be that lang/pl.txt and lang/en.txt should be in Resources/lang/ directory. Here is complete directory structure: ?? mul.framework ??? Headers -> Versions/Current/Headers ??? Resources -> Versions/Current/Resources ??? Versions ? ??? A ? ? ??? Headers ? ? ? ??? mul.h ? ? ??? Modules ? ? ? ??? module.modulemap ? ? ??? Resources ? ? ? ??? Info.plist ? ? ? ??? mulres.txt ? ? ? ??? lang ? ? ? ? ??? pl.txt ? ? ? ? ??? en.txt ? ? ? ??? resourcefile.txt ? ? ??? lang ? ? ? ??? en.txt ? ? ??? mul ? ??? Current -> A ??? mul -> Versions/Current/mul What do you think about that? Here is the source code: set_property(SOURCE module.modulemap PROPERTY MACOSX_PACKAGE_LOCATION "Modules") set_property( SOURCE lang/en.txt lang/pl.txt PROPERTY MACOSX_PACKAGE_LOCATION "lang") set(RESLIST mulres.txt lang/pl.txt resourcefile.txt ) add_library(mul SHARED mul.c mul.h module.modulemap lang/pl.txt lang/en.txt resourcefile.txt mulres.txt) # Create an iOS Framework bundle set_target_properties(mul PROPERTIES FRAMEWORK TRUE MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" PUBLIC_HEADER mul.h RESOURCE "${RESLIST}" ) Here is a CMakeLists.txt that will give you the desired layout. I also see that MACOSX_PACKAGE_LOCATION doesn't work with RESOURCE. set_property(SOURCE module.modulemap PROPERTY MACOSX_PACKAGE_LOCATION "Modules") set_property( SOURCE lang/pl.txt lang/en.txt PROPERTY MACOSX_PACKAGE_LOCATION "Resources/lang") set(RESLIST mulres.txt resourcefile.txt ) add_library(mul SHARED mul.c mul.h module.modulemap lang/pl.txt lang/en.txt resourcefile.txt mulres.txt) # Create an iOS Framework bundle set_target_properties(mul PROPERTIES FRAMEWORK TRUE MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" PUBLIC_HEADER mul.h RESOURCE "${RESLIST}" ) Now I'm wondering what does the RESOURCE target property do that MACOSX_PACKAGE_LOCATION doesn't already support? Clint -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruslan_baratov at yahoo.com Sat Dec 12 00:48:53 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Sat, 12 Dec 2015 12:48:53 +0700 Subject: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle. In-Reply-To: <1449889708273.6810@tomtom.com> References: <1449759153039.51334@tomtom.com> <1813369686.65723125.1449847446080.JavaMail.zimbra@elemtech.com> <1449853301422.90915@tomtom.com> <2780526.IlfGfMxfeF@stryke> <910432174.66323078.1449861684460.JavaMail.zimbra@elemtech.com> <1449866813173.56940@tomtom.com> <566B712B.6060503@yahoo.com> <1449889708273.6810@tomtom.com> Message-ID: <566BB545.3090701@yahoo.com> On 12-Dec-15 10:08, Bartosz Kosiorek wrote: > > Thanks Ruslan. > > > I would like to create instruction which is universal for all generators. > I think it's not possible. E.g. IOS_INSTALL_COMBINED will work only for Xcode. > Currently we would like to support both Make/Ninja and Xcode generators, > ... > because Make is much faster than Xcode generator, and we are using it > in our CI system. > Do you mean generate step or build? I've used to compile quite big projects like OpenCV with Xcode and according to the `top` it uses all my cores with clang++ at 100% CPU time. Can you show any benchmarks? Also note that Xcode can add some additional stuff, like dSYM: https://github.com/headupinclouds/gatherer/pull/69 > Make is also common for other architectures (Linux, QNX, Android etc.) > > > Unfortunately > > set(CMAKE_OSX_SYSROOT "iphoneos") > > is not working for me. > > It displays error: > > > /Users/warsaw/Perforce/cmake-dev/cmake-build/bin/cmake .. && > /Users/warsaw/Perforce/cmake-dev/cmake-build/bin/cmake --build . > -- Configuring done > -- Generating done > -- Build files have been written to: > /Users/warsaw/Perforce/cmake_ios_framework_with_resource2/builddir > [ 14%] Building C object > shared_empty/heymath/CMakeFiles/heymath.dir/add.c.o > clang: warning: no such sysroot directory: 'iphoneos' > ... > Do you have some tip for that? Yes, this hint was for Xcode generator. > > > After removing "-isysroot ${CMAKE_OSX_SYSROOT}" everything works > perfectly. Thanks > > Unfortunately CMAKE_XCODE_ATTRIBUTE_IPHONEOS_DEPLOYMENT_TARGET is not > working with Make. > Is it possible to introduce CMAKE_IOS_DEPLOYMENT_TARGET, as we already > have CMAKE_OSX_DEPLOYMENT_TARGET? Since OSX_ARCHITECTURES controls iOS architectures too I think request should sounds like "Extend OSX_DEPLOYMENT_TARGET property for iOS platform". > > I have attached my example script which I'm using. > ?Could you please modify it to be better (and still support other > generators)? I don't know how to use iOS target with Makefile generator. Some notes about project you've sent: * You need to add instructions to codesign your bundle * Instead of hardcoding `set(CMAKE_OSX_SYSROOT "/Applications/Xcode.app/.../iPhoneSimulator.sdk")` you can run `xcode-select -print-path` to detect location of default Xcode version * Should be `set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mios-version-min=8.0")` instead of `set(CMAKE_CXX_FLAGS "-mios-version-min=8.0")` otherwise some flags may be lost Ruslan > > Best Regards > Bartosz > > > > > > ------------------------------------------------------------------------ > *From:* Ruslan Baratov > *Sent:* Saturday, December 12, 2015 1:58 AM > *To:* Bartosz Kosiorek > *Cc:* clinton at elemtech.com; Gregor Jasny; CMake Developers > *Subject:* Re: [cmake-developers] Create subdirectories in Resource > directory for Frameworks and Application bundle. > On 12-Dec-15 03:46, Bartosz Kosiorek wrote: >> >> Hi >> >> To enable iOS build, I'm using following settings in CMakeLists.txt: >> >> >> set(APPLE_PLATFORM "iphonesimulator") > I think this one not needed. Can't find any place where it parsed. > >> set(CMAKE_OSX_SYSROOT >> "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk") > Can be set to: > > set(CMAKE_OSX_SYSROOT "iphoneos") > > in this case will support both simulator and device > >> set(CMAKE_C_FLAGS "-isysroot ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0") >> set(CMAKE_CXX_FLAGS "-isysroot ${CMAKE_OSX_SYSROOT} >> -mios-version-min=7.0") > You can set minimum version by > CMAKE_XCODE_ATTRIBUTE_IPHONEOS_DEPLOYMENT_TARGETvariable. > In case of `CMAKE_OSX_SYSROOT` variable is set to `iphoneos` option > `-isysroot` is redundant. > >> >> Do you think it should be documented? >> >> Where is the good place to do so? >> Maybe somewhere here: >> https://cmake.org/cmake/help/v3.4/variable/CMAKE_OSX_SYSROOT.html >> >> >> What do you think? >> >> ? >> >> >> ------------------------------------------------------------------------ >> *From:* clinton at elemtech.com >> *Sent:* Friday, December 11, 2015 8:21 PM >> *To:* Bartosz Kosiorek >> *Cc:* Bartosz Kosiorek; cmake-developers; Gregor Jasny >> *Subject:* Re: [cmake-developers] Create subdirectories in Resource >> directory for Frameworks and Application bundle. >> >> >> >> ----- On Dec 11, 2015, at 11:44 AM, Bartosz Kosiorek >> wrote: >> >> Hi >> >> Because there is difference between OS X and iOS Bundles >> directory structure (see: Apple specification >> https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html), >> >> in trunk (In CMake 3.5) RESOURCE property create corresponding >> directory structure. >> I have already fix that with: >> https://public.kitware.com/Bug/view.php?id=15848 >> >> Ok. I hadn't been following all your work. >> Also, I didn't see a toggle in the CMake code you sent to choose an >> iOS bundle instead of OS X bundles. How is that toggled? >> >> So RESOURCE gives you a level of abstraction: >> For OSX: >> it will create "Resource" directory >> >> For iOS it will create "flat" directory structure. >> >> In your example "Resource" directory will be created in both >> cases (for OSX and iOS). >> Which is wrong: >> For OSX: it should create "Resource" directory >> For iOS it will create "flat" directory structure. >> >> I could provide patch to fix that issue, if you agree with that. >> What do you think about that? >> Do you think the same should be applied to "Headers"? >> >> >> I think the abstraction seems reasonable, as well as what you are >> proposing. However, I'm not an Apple guru. >> I wonder if there are other Apple experts that can weigh in this if >> better feedback is needed. >> >> Clint >> >> >> >> Best Regards >> Bartosz >> >> >> >> 2015-12-11 19:06 GMT+01:00 Clinton Stimpson > >: >> >> >> >> On Friday, December 11, 2015 05:01:41 PM Bartosz Kosiorek wrote: >> > Thanks Clint >> > >> > Unfortunately MACOSX_PACKAGE_LOCATION is not working >> correctly with RESOURCE >> > property. For every resource which is marked as RESOURCE, >> will be placed in >> > root "Resources" directory. >> > >> > The CMake code below create following directory structure >> for OS X: >> > >> > ?? mul.framework >> > ??? Headers -> Versions/Current/Headers >> > ??? Resources -> Versions/Current/Resources >> > ??? Versions >> > ? ??? A >> > ? ? ??? Headers >> > ? ? ? ??? mul.h >> > ? ? ??? Modules >> > ? ? ? ??? module.modulemap >> > ? ? ??? Resources >> > ? ? ? ??? Info.plist >> > ? ? ? ??? mulres.txt >> > ? ? ? ??? pl.txt >> > ? ? ? ??? resourcefile.txt >> > ? ? ??? lang >> > ? ? ? ??? en.txt >> > ? ? ??? mul >> > ? ??? Current -> A >> > ??? mul -> Versions/Current/mul >> > >> > >> > As you can see eveything which is marked as "RESOURCE" will >> be placed in >> > Versions/A/ directory My expectation will be that >> lang/pl.txt and >> > lang/en.txt should be in Resources/lang/ directory. Here is >> complete >> > directory structure: >> > >> > ?? mul.framework >> > ??? Headers -> Versions/Current/Headers >> > ??? Resources -> Versions/Current/Resources >> > ??? Versions >> > ? ??? A >> > ? ? ??? Headers >> > ? ? ? ??? mul.h >> > ? ? ??? Modules >> > ? ? ? ??? module.modulemap >> > ? ? ??? Resources >> > ? ? ? ??? Info.plist >> > ? ? ? ??? mulres.txt >> > ? ? ? ??? lang >> > ? ? ? ? ??? pl.txt >> > ? ? ? ? ??? en.txt >> > ? ? ? ??? resourcefile.txt >> > ? ? ??? lang >> > ? ? ? ??? en.txt >> > ? ? ??? mul >> > ? ??? Current -> A >> > ??? mul -> Versions/Current/mul >> > >> > >> > What do you think about that? >> > >> > Here is the source code: >> > >> > set_property(SOURCE module.modulemap >> > PROPERTY MACOSX_PACKAGE_LOCATION "Modules") >> > >> > set_property( >> > SOURCE lang/en.txt lang/pl.txt >> > PROPERTY MACOSX_PACKAGE_LOCATION "lang") >> > >> > set(RESLIST >> > mulres.txt >> > lang/pl.txt >> > resourcefile.txt >> > ) >> > >> > add_library(mul SHARED >> > mul.c >> > mul.h >> > module.modulemap >> > lang/pl.txt >> > lang/en.txt >> > resourcefile.txt >> > mulres.txt) >> > >> > # Create an iOS Framework bundle >> > set_target_properties(mul PROPERTIES >> > FRAMEWORK TRUE >> > MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul >> > MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 >> > MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 >> > XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" >> > PUBLIC_HEADER mul.h >> > RESOURCE "${RESLIST}" >> > ) >> >> >> Here is a CMakeLists.txt that will give you the desired layout. >> I also see that MACOSX_PACKAGE_LOCATION doesn't work with >> RESOURCE. >> >> >> set_property(SOURCE module.modulemap >> PROPERTY MACOSX_PACKAGE_LOCATION "Modules") >> >> set_property( >> SOURCE lang/pl.txt lang/en.txt >> PROPERTY MACOSX_PACKAGE_LOCATION "Resources/lang") >> >> set(RESLIST >> mulres.txt >> resourcefile.txt >> ) >> >> add_library(mul SHARED >> mul.c >> mul.h >> module.modulemap >> lang/pl.txt >> lang/en.txt >> resourcefile.txt >> mulres.txt) >> >> # Create an iOS Framework bundle >> set_target_properties(mul PROPERTIES >> FRAMEWORK TRUE >> MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul >> MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 >> MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 >> XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" >> PUBLIC_HEADER mul.h >> RESOURCE "${RESLIST}" >> ) >> >> >> Now I'm wondering what does the RESOURCE target property do that >> MACOSX_PACKAGE_LOCATION doesn't already support? >> >> Clint >> -- >> >> 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 >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Sat Dec 12 06:43:54 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 12 Dec 2015 06:43:54 -0500 Subject: [cmake-developers] [CMake 0015880]: Many test failures with cmake 3.4.1 testsuite Message-ID: <87e2429a23b42221c5541adf9e4cfc80@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15880 ====================================================================== Reported By: Dennis Clarke Assigned To: ====================================================================== Project: CMake Issue ID: 15880 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-12-12 06:43 EST Last Modified: 2015-12-12 06:43 EST ====================================================================== Summary: Many test failures with cmake 3.4.1 testsuite Description: Extracted cmake-3.4.1 sources and did : 1) ./bootstrap This seemed to run fine. 2) /usr/local/bin/gmake This seems to run fine. 3) /usr/local/bin/gmake test This step produces many failures. Steps to Reproduce: 1) Extract cmake source. 2) Set up environemt for reasonable compile with CFLAGS and CXXFLAGS that enable later debuging if needed. AR=/usr/ccs/bin/ar AS=/usr/ccs/bin/as BUILD=/usr/local/build CC=/opt/solarisstudio12.4/bin/cc CFLAGS=-errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 \ -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs \ -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 \ -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 CONFIG_SHELL=/usr/local/bin/bash CPPFLAGS=-I/usr/local/include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE CXXFLAGS=-dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 \ -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 \ -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs \ -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO CXX=/opt/solarisstudio12.4/bin/CC EDITOR=/usr/xpg6/bin/vi GREP=/usr/local/bin/ggrep HOME=/export/home/dclarke LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_MONETARY=en_US.UTF-8 LC_NUMERIC=en_US.UTF-8 LC_TIME=en_US.UTF-8 LD_OPTIONS=-64 -R/usr/local/lib/:/usr/local/lib -L/usr/local/lib/:/usr/local/lib LD_RUN_PATH=/usr/local/lib LD=/usr/ccs/bin/sparcv9/ld LIBTOOL=/usr/local/bin/libtool M4=/usr/local/bin/gm4 MAKE=/usr/local/bin/gmake MANPATH=/usr/share/man:/usr/X11/share/man NM=/usr/ccs/bin/sparcv9/nm -p PAGER=/usr/xpg4/bin/more PATH=/usr/xpg6/bin:/usr/xpg4/bin:/usr/ccs/bin:/opt/solarisstudio12.4/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/dt/bin:/usr/openwin/bin:/opt/schily/bin PERL=/usr/local/bin/perl PKG_CONFIG_PATH=/usr/local/lib/pkgconfig PWD=/usr/local/build/cmake-3.4.1_SunOS5.10_sparcv9.001 SED=/usr/local/bin/gsed SHELL=/usr/xpg4/bin/sh SHLVL=1 SRC=/usr/local/src TERM=xterm TZ=GMT0 VISUAL=/usr/xpg6/bin/vi XTERM_LOCALE=en_US.UTF-8 3) run bootstrap and see output as detailed in attached log file cmake-3.4.1_SunOS5.10_sparcv9.001.bootstrap.log.gz 4) run GNU gmake and see output as detailed in log file cmake-3.4.1_SunOS5.10_sparcv9.001.build.log 5) run GNU make test and see many failures detailed in log file cmake-3.4.1_SunOS5.10_sparcv9.001.test.log Additional Information: Any test failure from the test suite is reasonable grounds to reject install of the software. If there is some way to determine that these failures are false or not relevant then that would allow the cmake to be installed. At the moment, even the very first test fails : Running tests... Test project /usr/local/build/cmake-3.4.1_SunOS5.10_sparcv9.001 Guessing configuration NoConfig Start 1: SystemInformationNew 1/417 Test https://cmake.org/Bug/view.php?id=1: SystemInformationNew .............................***Failed 3.33 sec etc. I will say that some strange output was seen during the bootstrap phase thus : -- Check size of __int64 -- Check size of __int64 - failed This integer type is not defined within IEEE Std 1003.1, 2013 Edition nor in ISO/IEC 9899:1990 Programming language - C or anywhere else I can find. The leading double underscore suggests this is some internal typedef buried somewhere. I also see a ton of failures for curl interfaces and yet I do have curl 7.45.0 installed : curl 7.45.0 (sparc-sun-solaris2.10) libcurl/7.45.0 OpenSSL/1.0.2e zlib/1.2.8 libidn/1.29 libssh2/1.4.3 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp Features: IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP UnixSockets Most likely this is a PATH issue. Not sure why cmake needs access to curl in any case. Is there a way to build a minimal cmake that will pass its own test suite on a production Solaris 10 server? ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-12-12 06:43 Dennis Clarke New Issue 2015-12-12 06:43 Dennis Clarke File Added: cmake_3.4.1_logs.tar.xz ====================================================================== From mantis at public.kitware.com Sat Dec 12 12:48:33 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 12 Dec 2015 12:48:33 -0500 Subject: [cmake-developers] [CMake 0015881]: fatal: symbol referencing errors. Linking CXX executable ../bin/ccmake Message-ID: <027699bf383189db97ed4f7dcda4fb8a@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15881 ====================================================================== Reported By: Dennis Clarke Assigned To: ====================================================================== Project: CMake Issue ID: 15881 Category: CMake Reproducibility: have not tried Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-12-12 12:48 EST Last Modified: 2015-12-12 12:48 EST ====================================================================== Summary: fatal: symbol referencing errors. Linking CXX executable ../bin/ccmake Description: Tried bootstrap thus : ./bootstrap --no-qt-gui --system-curl --system-expat --system-zlib --system-bzip2 --no-system-libarchive During the compile I see the final link stage is confused about where to find libz : [ 92%] Linking CXX executable ../bin/ccmake Undefined first referenced symbol in file gzopen64 libCMakeLib.a(cmGeneratedFileStream.cxx.o) ld: fatal: symbol referencing errors. No output written to ../bin/ccmake gmake[2]: *** [bin/ccmake] Error 2 gmake[1]: *** [Source/CMakeFiles/ccmake.dir/all] Error 2 gmake: *** [all] Error 2 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-12-12 12:48 Dennis Clarke New Issue ====================================================================== From mantis at public.kitware.com Sat Dec 12 13:26:17 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 12 Dec 2015 13:26:17 -0500 Subject: [cmake-developers] [CMake 0015882]: bootstrap fails with Undefined symbol nanosleep Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15882 ====================================================================== Reported By: Dennis Clarke Assigned To: ====================================================================== Project: CMake Issue ID: 15882 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-12-12 13:26 EST Last Modified: 2015-12-12 13:26 EST ====================================================================== Summary: bootstrap fails with Undefined symbol nanosleep Description: $ LD_LIBRARY_PATH=/usr/local/lib:/usr/local/ssl/lib ; export LD_LIBRARY_PATH $ ./bootstrap --no-qt-gui --system-curl --system-expat --system-zlib --system-bzip2 --no-system-libarchive . . . /opt/solarisstudio12.4/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -library=stlport4 -I/usr/local/build/cmake-3.4.1_SunOS5.10_sparcv9.003/Bootstrap.cmk -I/usr/local/build/cmake-3.4.1_SunOS5.10_sparcv9.003/Source -I/usr/local/build/cmake-3.4.1_SunOS5.10_sparcv9.003/Bootstrap.cmk cmake.o cmakemain.o cmcmd.o cmCommandArgumentLexer.o cmCommandArgumentParser.o cmCommandArgumentParserHelper.o cmCommonTargetGenerator.o cmCPackPropertiesGenerator.o cmDefinitions.o cmDepends.o cmDependsC.o cmDocumentationFormatter.o cmPolicies.o cmProperty.o cmPropertyMap.o cmPropertyDefinition.o cmPropertyDefinitionMap.o cmMakeDepend.o cmMakefile.o cmExportFileGenerator.o cmExportInstallFileGenerator.o cmExportTryCompileFileGenerator.o cmExportSet.o cmExportSetMap.o cmExternalMakefileProjectGenerator.o cmGeneratorExpressionEvaluationFile.o cmGeneratedFileStream.o cmGeneratorTarget.o cmGeneratorExpressionContext.o cmGeneratorExpressionDAGChecker.o cmGeneratorExpressionEvaluator.o cmGeneratorExpressionLexer.o cmGeneratorExpressionNode.o cmGeneratorExpressionParser.o cmGeneratorExpression.o cmGlobalCommonGenerator.o cmGlobalGenerator.o cmInstallDirectoryGenerator.o cmLocalCommonGenerator.o cmLocalGenerator.o cmInstalledFile.o cmInstallGenerator.o cmInstallExportGenerator.o cmInstallFilesGenerator.o cmInstallScriptGenerator.o cmInstallTargetGenerator.o cmScriptGenerator.o cmSourceFile.o cmSourceFileLocation.o cmState.o cmSystemTools.o cmTestGenerator.o cmVersion.o cmFileTimeComparison.o cmGlobalUnixMakefileGenerator3.o cmLocalUnixMakefileGenerator3.o cmMakefileExecutableTargetGenerator.o cmMakefileLibraryTargetGenerator.o cmMakefileTargetGenerator.o cmMakefileUtilityTargetGenerator.o cmOutputConverter.o cmOSXBundleGenerator.o cmNewLineStyle.o cmBootstrapCommands1.o cmBootstrapCommands2.o cmCommandsForBootstrap.o cmTarget.o cmTest.o cmCustomCommand.o cmCustomCommandGenerator.o cmCacheManager.o cmListFileCache.o cmComputeLinkDepends.o cmComputeLinkInformation.o cmOrderDirectories.o cmComputeTargetDepends.o cmComputeComponentGraph.o cmExprLexer.o cmExprParser.o cmExprParserHelper.o cmListFileLexer.o Directory.o EncodingCXX.o FStream.o Glob.o RegularExpression.o SystemTools.o EncodingC.o ProcessUNIX.o String.o System.o Terminal.o -o cmake Undefined first referenced symbol in file nanosleep /usr/local/lib/libstlport.a(__tQqIQdun-yXoTTDUVT.o) bool std::less::operator()(const unsigned long&,const unsigned long&)const cmBootstrapCommands2.o ld: fatal: symbol referencing errors. No output written to cmake gmake: *** [cmake] Error 2 --------------------------------------------- Error when bootstrapping CMake: Problem while running /usr/local/bin/gmake --------------------------------------------- Log of errors: /usr/local/build/cmake-3.4.1_SunOS5.10_sparcv9.003/Bootstrap.cmk/cmake_bootstrap.log --------------------------------------------- ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-12-12 13:26 Dennis Clarke New Issue ====================================================================== From mantis at public.kitware.com Sat Dec 12 13:34:52 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 12 Dec 2015 13:34:52 -0500 Subject: [cmake-developers] [CMake 0015883]: cmake bootstrap fails with Cannot find appropriate C compiler on this system. Message-ID: <22428df8a593dd821ddc0a0aeb81bd11@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15883 ====================================================================== Reported By: Dennis Clarke Assigned To: ====================================================================== Project: CMake Issue ID: 15883 Category: CMake Reproducibility: have not tried Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-12-12 13:34 EST Last Modified: 2015-12-12 13:34 EST ====================================================================== Summary: cmake bootstrap fails with Cannot find appropriate C compiler on this system. Description: Strange : $ echo $CC /opt/solarisstudio12.4/bin/cc $ /opt/solarisstudio12.4/bin/cc -V cc: Sun C 5.13 SunOS_sparc 2014/10/20 ./bootstrap --no-qt-gui --no-system-libarchive CMake 3.4.1, Copyright 2000-2015 Kitware, Inc. --------------------------------------------- Error when bootstrapping CMake: Cannot find appropriate C compiler on this system. Please specify one using environment variable CC. See cmake_bootstrap.log for compilers attempted. --------------------------------------------- Log of errors: /usr/local/build/cmake-3.4.1_SunOS5.10_sparcv9.004/Bootstrap.cmk/cmake_bootstrap.log --------------------------------------------- ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-12-12 13:34 Dennis Clarke New Issue ====================================================================== From david.gobbi at gmail.com Sat Dec 12 14:12:32 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Sat, 12 Dec 2015 12:12:32 -0700 Subject: [cmake-developers] [PATCH] FindOpenGL: Don't add AGL to OPENGL_LIBRARIES on OS X. Message-ID: CMake had been setting OPENGL_glu_LIBRARY to AGL.framework, even though AGL is not GLU. AGL is simply the GL component for the deprecated Carbon framework. GLU is provided by OpenGL.framework. A side effect of the old behavior was that if AGL was not found (it is absent from OS X SDK 10.10 or later), then OPENGL_GLU_FOUND would be incorrectly set to "NO". -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-FindOpenGL-Don-t-add-AGL-to-OPENGL_LIBRARIES-on-OS-X.patch Type: application/octet-stream Size: 1887 bytes Desc: not available URL: From rleigh at codelibre.net Sun Dec 13 13:19:54 2015 From: rleigh at codelibre.net (Roger Leigh) Date: Sun, 13 Dec 2015 18:19:54 +0000 Subject: [cmake-developers] CMakeFindDependencyMacro limitations Message-ID: <566DB6CA.1060801@codelibre.net> I've run into a few limitations in find_dependency. I'm not sure if these are by design or could be fixed, so this is really a request for further explanation or design rationale. The first issue is this: if (NOT ${dep}_FOUND) This seems to be making the assumption that the found variable matches the dependency name, but the case used varies between modules and the name is case sensitive, from my reading of cmake-language. Is this correct? Even if so, should this optimisation be put here rather than in find_package itself? If case sensitivity/naming is an issue, could the _FOUND variable be passed in as an argument, leaving the existing behaviour as the default if unspecified? The reason for stripping EXACT isn't clear. If my package has a strict requirement on another package, whether the caller has an exact requirement for the version of my package has no bearing on the requirements I have for my dependencies as far as I understand. What's the reason for the existing behaviour? Support for find_package arguments is limited to the dependency name and optionally the version. I can understand why REQUIRED and related arguments are omitted--that is why find_dependency exists--but I'd quite like to be able to specify COMPONENTS where needed e.g. with FindBoost, and this is not currently possible. I was wondering if we could perhaps make find_dependency handle and pass through /all/ find_package arguments, minus REQUIRED/QUIET, so that find_dependency can expose the additional functionality offered by find_package. Some may not be useful, in which case they could be omitted, but some like COMPONENTS may be required for the find_package call to be useful. Regards, Roger From gjasny at googlemail.com Sun Dec 13 13:52:10 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Sun, 13 Dec 2015 19:52:10 +0100 Subject: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle. In-Reply-To: <910432174.66323078.1449861684460.JavaMail.zimbra@elemtech.com> References: <1449759153039.51334@tomtom.com> <1813369686.65723125.1449847446080.JavaMail.zimbra@elemtech.com> <1449853301422.90915@tomtom.com> <2780526.IlfGfMxfeF@stryke> <910432174.66323078.1449861684460.JavaMail.zimbra@elemtech.com> Message-ID: <566DBE5A.1030500@googlemail.com> On 11/12/15 20:21, clinton at elemtech.com wrote: > ----- On Dec 11, 2015, at 11:44 AM, Bartosz Kosiorek wrote: >> Because there is difference between OS X and iOS Bundles directory structure >> (see: Apple specification >> https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html >> ), >> in trunk (In CMake 3.5) RESOURCE property create corresponding directory >> structure. >> I have already fix that with: >> https://public.kitware.com/Bug/view.php?id=15848 > > Ok. I hadn't been following all your work. > Also, I didn't see a toggle in the CMake code you sent to choose an iOS bundle instead of OS X bundles. How is that toggled? See cmMakefile::PlatformIsAppleIos() https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmMakefile.cxx;h=1b0a99ae84932af665360f63bf8bba8d7663ef8e;hb=HEAD#l2404 Basically it's looking at the CMAKE_OSX_SYSROOT variable. -Gregor From gjasny at googlemail.com Sun Dec 13 13:58:08 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Sun, 13 Dec 2015 19:58:08 +0100 Subject: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle. In-Reply-To: <2235818.ev9kN26Y2h@stryke> References: <1449759153039.51334@tomtom.com> <910432174.66323078.1449861684460.JavaMail.zimbra@elemtech.com> <1449866813173.56940@tomtom.com> <2235818.ev9kN26Y2h@stryke> Message-ID: <566DBFC0.5020602@googlemail.com> On 11/12/15 22:16, Clinton Stimpson wrote: >> To enable iOS build, I'm using following settings in CMakeLists.txt: >> > >> > >> > set(APPLE_PLATFORM "iphonesimulator") >> > set(CMAKE_OSX_SYSROOT >> > "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platf >> > orm/Developer/SDKs/iPhoneSimulator.sdk") > set(CMAKE_C_FLAGS "-isysroot >> > ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0") set(CMAKE_CXX_FLAGS "-isysroot >> > ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0") >> > Do you think it should be documented? As far as I see one should create a Toolchain file for all Apple SDKs (also macosx) because one has to modify header and library lookup paths to not look into /usr. See for example https://cmake.org/gitweb?p=cmake.git;a=blob;f=Tests/RunCMake/XcodeProject/osx.cmake;hb=HEAD I planned to create an official macosx, iphone, etc. Toolchain files for CMake but did not find the time to work on it. Thanks, Gregor From attila.krasznahorkay at gmail.com Mon Dec 14 08:37:23 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Mon, 14 Dec 2015 14:37:23 +0100 Subject: [cmake-developers] Proposal to teach cmDepends to only take dependencies from the source tree In-Reply-To: <20151209143855.GA22671@megas.khq.kitware.com> References: <86B42AB9-1BD5-49A3-921B-3FCB55D8D9B9@gmail.com> <20151208161407.GB2107@megas.khq.kitware.com> <362406117.GZvUB7WoTK@tuxedo.neundorf.net> <5EE91C0E-5CC5-4155-B4F8-9AE9FFBE3D09@gmail.com> <20151209143855.GA22671@megas.khq.kitware.com> Message-ID: <3E1EC9FD-B78B-499C-A99E-7AB6D1450616@gmail.com> Dear All, I was hoping to get some feedback from the developers on which direction to take this in. As I wrote before, I'm happy to help. But I don't want to spend time on an implementation that people will not accept in the end. I'd like us to first agree on how the code should behave after the addition of this new feature. Cheers, Attila > On 09 Dec 2015, at 15:38, Ben Boeckel wrote: > > On Wed, Dec 09, 2015 at 09:19:45 +0100, Attila Krasznahorkay wrote: >> I myself am on the side of simplicity. Using regular expressions would >> allow us to do what I want. But if >95% of the people using this new >> possibility would use it exactly like I plan to, then implementing it >> in a more complicated way than necessary would just be a bad design >> choice. > > Do you have performance numbers for the change in your build between > using include_directories (or target_include_directories), with and > without SYSTEM, each with and without this change? > > --Ben From brad.king at kitware.com Mon Dec 14 09:42:32 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 14 Dec 2015 09:42:32 -0500 Subject: [cmake-developers] parallel install of different cmake versions In-Reply-To: <566B5F4D.1030701@cora.nwra.com> References: <566B5F4D.1030701@cora.nwra.com> Message-ID: <566ED558.5030402@kitware.com> On 12/11/2015 06:42 PM, Orion Poplawski wrote: > For Fedora EPEL we often end up packaging newer versions of cmake as cmakeXY > (e.g. cmake34) that can be installed in parallel with the system cmake. This > is a fairly invasive process. I'm attaching the current patch I'm working on > for this. Is there any interest in cmake itself for supporting this kind of > thing? Not particularly. That does look pretty invasive. Why not just install it to /usr/lib/cmake34 with normal names and symlink the versioned names? E.g. /usr/bin/cmake34 -> /usr/lib/cmake34/bin/cmake /usr/bin/ctest34 -> /usr/lib/cmake34/bin/ctest ... I have many different CMake versions installed on my system in different directories and use aliases or symlinks to reference them without being in my PATH directly. -Brad From brad.king at kitware.com Mon Dec 14 09:48:35 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 14 Dec 2015 09:48:35 -0500 Subject: [cmake-developers] [PATCH] FindOpenGL: Don't add AGL to OPENGL_LIBRARIES on OS X. In-Reply-To: References: Message-ID: <566ED6C3.7050706@kitware.com> On 12/12/2015 02:12 PM, David Gobbi wrote: > CMake had been setting OPENGL_glu_LIBRARY to AGL.framework, even > though AGL is not GLU. AGL is simply the GL component for the > deprecated Carbon framework. GLU is provided by OpenGL.framework. > > A side effect of the old behavior was that if AGL was not found > (it is absent from OS X SDK 10.10 or later), then OPENGL_GLU_FOUND > would be incorrectly set to "NO". Thanks. I'm not familiar with those roles myself so I've long wondered why we used AGL for GLU. Applied: FindOpenGL: Don't add AGL to OPENGL_LIBRARIES on OS X. https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=08580be2 -Brad From david.gobbi at gmail.com Mon Dec 14 09:56:30 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 14 Dec 2015 07:56:30 -0700 Subject: [cmake-developers] [PATCH] FindOpenGL: Don't add AGL to OPENGL_LIBRARIES on OS X. In-Reply-To: <566ED6C3.7050706@kitware.com> References: <566ED6C3.7050706@kitware.com> Message-ID: On Mon, Dec 14, 2015 at 7:48 AM, Brad King wrote: > On 12/12/2015 02:12 PM, David Gobbi wrote: > > CMake had been setting OPENGL_glu_LIBRARY to AGL.framework, even > > though AGL is not GLU. AGL is simply the GL component for the > > deprecated Carbon framework. GLU is provided by OpenGL.framework. > > > > A side effect of the old behavior was that if AGL was not found > > (it is absent from OS X SDK 10.10 or later), then OPENGL_GLU_FOUND > > would be incorrectly set to "NO". > > Thanks. I'm not familiar with those roles myself so I've long wondered > why we used AGL for GLU. Applied: > > FindOpenGL: Don't add AGL to OPENGL_LIBRARIES on OS X. > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=08580be2 Carbon + AGL are like x11 + glx and Windows + wgl. Thanks for the quick reply. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Mon Dec 14 10:56:08 2015 From: eric.noulard at gmail.com (Eric Noulard) Date: Mon, 14 Dec 2015 16:56:08 +0100 Subject: [cmake-developers] parallel install of different cmake versions In-Reply-To: <566ED558.5030402@kitware.com> References: <566B5F4D.1030701@cora.nwra.com> <566ED558.5030402@kitware.com> Message-ID: 2015-12-14 15:42 GMT+01:00 Brad King : > On 12/11/2015 06:42 PM, Orion Poplawski wrote: > > For Fedora EPEL we often end up packaging newer versions of cmake as > cmakeXY > > (e.g. cmake34) that can be installed in parallel with the system cmake. > This > > is a fairly invasive process. I'm attaching the current patch I'm > working on > > for this. Is there any interest in cmake itself for supporting this > kind of > > thing? > > Not particularly. That does look pretty invasive. > > Why not just install it to /usr/lib/cmake34 with normal names and symlink > the versioned names? E.g. > > /usr/bin/cmake34 -> /usr/lib/cmake34/bin/cmake > /usr/bin/ctest34 -> /usr/lib/cmake34/bin/ctest > +1 Personnally when I installed several version of CMake I do install them with a particular prefix and then I use update-alternatives(1) to install proper symlinks to the specific location. I switch from one version to another using update-alternatives(1). This can certainly be used on Fedora/EPEL as well: https://fedoraproject.org/wiki/Packaging:Alternatives -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Mon Dec 14 15:36:03 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Mon, 14 Dec 2015 12:36:03 -0800 (PST) Subject: [cmake-developers] [CMake] How to set _default_ timeout for the ctest command? (fwd) Message-ID: I would appreciate it if a CMake developer who is familiar with the CTest timeout logic would answer my question below that was addressed to "@CMake developers:". Without such an answer (even if the conclusion is there is no way for an individual software package such as lapack to set a different _default_ timeout for CTest other than 1500 seconds), I will not be able to figure out what to advise the lapack developers. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ---------- Forwarded message ---------- Date: Wed, 9 Dec 2015 19:06:00 -0800 (PST) From: Alan W. Irwin To: Marcel Loose Cc: cmake at cmake.org Subject: Re: [CMake] How to set _default_ timeout for the ctest command? On 2015-12-09 09:23+0100 Marcel Loose wrote: > Hi Alan, > > Just by experimenting, I discovered that you also need to set > DART_TESTING_TIMEOUT. I'm not sure what the relationship (if any) is > between CTEST_TEST_TIMEOUT and DART_TESTING_TIMEOUT. I set them both in > the file CTestConfig.cmake. I get the feeling that DART_TESTING_TIMEOUT > is there for less than historic reasons. Maybe someone from Kitware can > shed a light on this. Thanks, Marcel, for trying those experiments. I tried some additional experiments and found that all that is needed is to set the CTEST_TEST_TIMEOUT value before CTest is included in my top-level CMakeLists.txt file. (My previous experiment set that value after the include, but before the first add_test command.) Note that I do not use CTestConfig.cmake at all. So the current experimental logic is # Control the default timeout for all ctests. set(CTEST_TEST_TIMEOUT 1) include(CTest) Those commands generate the following timeout results in the build tree. software at raven> find . -type f |xargs grep -i timeout ./CMakeCache.txt:DART_TESTING_TIMEOUT:STRING=1 ./CMakeCache.txt://ADVANCED property for variable: DART_TESTING_TIMEOUT ./CMakeCache.txt:DART_TESTING_TIMEOUT-ADVANCED:INTERNAL=1 ./DartConfiguration.tcl:# TimeOut is the amount of time in seconds to wait for processes ./DartConfiguration.tcl:# to complete during testing. After TimeOut seconds, the ./DartConfiguration.tcl:TimeOut: 1 ./DartConfiguration.tcl:# For CTest submissions that timeout, these options So for this case, DART_TESTING_TIMEOUT is automatically set to the specified CTEST_TEST_TIMEOUT value. (If CTEST_TEST_TIMEOUT is not set, the cached value of DART_TESTING_TIMEOUT is 1500, and the value of the timeout in DartConfiguration.tcl is also set to 1500). Afterwards, ctest timed out at 1 second for all tests that exceeded that value, but it turns out that is a hard-coded value which cannot be superseded by the ctest --timeout option. So this approach is not really ideal for the lapack developers who will want to increase the default limit by only an order of magnitude or less to substantially reduce the probability someone with a slow computer or special circumstances will have to override using the ctest --timeout option, but that change likely will not reduce that probability to zero so keeping the ability to override the lapack timeout default by the ctest --timeout option is still likely imporatant to them. @CMake developers: The documentation of CTEST_TEST_TIMEOUT (and DART_TESTING_TIMEOUT) includes the following language: "The default timeout for each test if not specified by the `TIMEOUT` test property. Also, the documentation of the ctest --timeout option says: `--timeout ` Set a global timeout on all tests. This option will set a global timeout on all tests that do not already have a timeout set on them. So I guess it could be argued that CTEST_TEST_TIMEOUT does impose a specific timeout on all tests, and that is why the --timeout option is being ignored for this case. But that is not particularly useful behaviour, and it would be far better in my opinion for the --timeout option to work for all tests where the TIMEOUT test property has not been specifically set by the project's build system. I would appreciate some further investigation of these matters by a knowledgable CMake developer, and if it turns out this issue is actually caused by a cmake or ctest bug, then I would be willing to write up the appropriate bug report if it turns out an instantaneous fix could not be made. I also tried the experiment of dropping the setting of CTEST_TEST_TIMEOUT and using set_tests_properties to set the TIMEOUT for individual commands, but consistent with the above wording of the documentation, the ctest --timeout option was ignored for this case. I am OK with that limitation so long (see above) as some change is made so CTEST_TEST_TIMEOUT is interpreted exactly the same as the 1500 default timeout, i.e., the CTEST_TEST_TIMEOUT value can be overridden by the ctest --timeout option. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ -- 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 From matthias at maennich.net Mon Dec 14 16:52:09 2015 From: matthias at maennich.net (=?UTF-8?Q?Matthias_M=C3=A4nnich?=) Date: Mon, 14 Dec 2015 22:52:09 +0100 Subject: [cmake-developers] [PATCH] CMakeParseArguments: Test suite and native implementation Message-ID: Hi, This is my pull request [1] brought to the list. This adds a test suite for the CMakeParseArguments module. In addition the second change implements cmake_parse_arguments(...) as native command. In our project we saw that cmake_parse_arguments is actually called a lot of times due to macro expansion and we could almost halve our configure time by using a native implementation of cmake_parse_arguments. This implementation follows the implementation of the former macro and both implementations of course pass the added test suite. I added a third change that makes cmake_parse_arguments() emit a warning in case keywords are specified more than once. An error instead actually would break compatibility (which is why I also made it a separate commit) for some probably unused corner cases. But in my opinion this improves the implementation as I assume that most of the duplicate specifications are actual errors that else get silently ignored. In a later CMake version one could even emit an error in this case but as it would break compatibility it should be introduced along with a policy. Best regards, Matthias --- [1] https://github.com/Kitware/CMake/pull/202 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-cmake_parse_arguments-consider-duplicate-keyword-as-.patch Type: text/x-patch Size: 6426 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-CMakeParseArguments-replace-by-native-cmake_parse_ar.patch Type: text/x-patch Size: 23364 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-CMakeParseArguments-add-a-RunCMake-test-suite.patch Type: text/x-patch Size: 10433 bytes Desc: not available URL: From attila.krasznahorkay at gmail.com Tue Dec 15 01:09:39 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Tue, 15 Dec 2015 07:09:39 +0100 Subject: [cmake-developers] [CMake] How to set _default_ timeout for the ctest command? (fwd) In-Reply-To: References: Message-ID: Hi Alan, Are you just looking for the TIMEOUT property on the tests? https://cmake.org/cmake/help/v3.0/command/set_tests_properties.html This is something that I managed to find with the most basic google-ing myself. :-/ And I use it like: set_tests_properties( ${testName}Test PROPERTIES TIMEOUT 120 ) Or would you like to be able to set some global property/variable that would set the default timeout for all the created tests without you having to set these things individually? (I just wrote a wrapper function to set up all my tests in the way that I wanted to.) Best, Attila > On Dec 14, 2015, at 9:36 PM, Alan W. Irwin wrote: > > I would appreciate it if a CMake developer who is familiar with the CTest timeout > logic would answer my question below that was addressed to "@CMake developers:". > > Without such an answer (even if the conclusion is there is no way for > an individual software package such as lapack to set a different > _default_ timeout for CTest other than 1500 seconds), I will not be > able to figure out what to advise the lapack developers. > > Alan > > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > ---------- Forwarded message ---------- > Date: Wed, 9 Dec 2015 19:06:00 -0800 (PST) > From: Alan W. Irwin > To: Marcel Loose > Cc: cmake at cmake.org > Subject: Re: [CMake] How to set _default_ timeout for the ctest command? > > On 2015-12-09 09:23+0100 Marcel Loose wrote: > >> Hi Alan, >> Just by experimenting, I discovered that you also need to set >> DART_TESTING_TIMEOUT. I'm not sure what the relationship (if any) is >> between CTEST_TEST_TIMEOUT and DART_TESTING_TIMEOUT. I set them both in >> the file CTestConfig.cmake. I get the feeling that DART_TESTING_TIMEOUT >> is there for less than historic reasons. Maybe someone from Kitware can >> shed a light on this. > > Thanks, Marcel, for trying those experiments. > > I tried some additional experiments and found that all that is needed is > to set the CTEST_TEST_TIMEOUT value before CTest is included in my > top-level CMakeLists.txt file. (My previous experiment set that value > after the include, but before the first add_test command.) Note that > I do not use CTestConfig.cmake at all. > > So the current experimental logic is > # Control the default timeout for all ctests. > set(CTEST_TEST_TIMEOUT 1) > include(CTest) > > Those commands generate the following timeout results in the build tree. > > software at raven> find . -type f |xargs grep -i timeout > ./CMakeCache.txt:DART_TESTING_TIMEOUT:STRING=1 > ./CMakeCache.txt://ADVANCED property for variable: DART_TESTING_TIMEOUT > ./CMakeCache.txt:DART_TESTING_TIMEOUT-ADVANCED:INTERNAL=1 > ./DartConfiguration.tcl:# TimeOut is the amount of time in seconds to wait for processes > ./DartConfiguration.tcl:# to complete during testing. After TimeOut seconds, the > ./DartConfiguration.tcl:TimeOut: 1 > ./DartConfiguration.tcl:# For CTest submissions that timeout, these options > > So for this case, DART_TESTING_TIMEOUT is automatically set to the > specified CTEST_TEST_TIMEOUT value. (If CTEST_TEST_TIMEOUT is not set, > the cached value of DART_TESTING_TIMEOUT is 1500, and the value of the > timeout in DartConfiguration.tcl is also set to 1500). > > Afterwards, ctest timed out at 1 second for all tests that exceeded > that value, but it turns out that is a hard-coded value which cannot > be superseded by the ctest --timeout option. So this approach is not > really ideal for the lapack developers who will want to increase the > default limit by only an order of magnitude or less to substantially > reduce the probability someone with a slow computer or special > circumstances will have to override using the ctest --timeout option, > but that change likely will not reduce that probability to zero so > keeping the ability to override the lapack timeout default by the > ctest --timeout option is still likely imporatant to them. > > @CMake developers: > > The documentation of CTEST_TEST_TIMEOUT (and DART_TESTING_TIMEOUT) > includes the following language: > > "The default timeout for each test if > not specified by the `TIMEOUT` test property. > > Also, the documentation of the ctest --timeout option says: > > `--timeout ` > Set a global timeout on all tests. > > This option will set a global timeout on all tests that do not > already have a timeout set on them. > > So I guess it could be argued that CTEST_TEST_TIMEOUT does impose a > specific timeout on all tests, and that is why the --timeout option is > being ignored for this case. But that is not particularly useful > behaviour, and it would be far better in my opinion for the --timeout > option to work for all tests where the TIMEOUT test property has > not been specifically set by the project's build system. > > I would appreciate some further investigation of these matters by a > knowledgable CMake developer, and if it turns out this issue is > actually caused by a cmake or ctest bug, then I would be willing to > write up the appropriate bug report if it turns out an instantaneous > fix could not be made. > > I also tried the experiment of dropping the setting of > CTEST_TEST_TIMEOUT and using set_tests_properties to set the TIMEOUT > for individual commands, but consistent with the above wording of the > documentation, the ctest --timeout option was ignored for this case. I > am OK with that limitation so long (see above) as some change is made > so CTEST_TEST_TIMEOUT is interpreted exactly the same as the 1500 > default timeout, i.e., the CTEST_TEST_TIMEOUT value can be overridden > by the ctest --timeout option. > > Alan > > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > -- > > 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 > -- > > 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 From irwin at beluga.phys.uvic.ca Tue Dec 15 02:01:31 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Mon, 14 Dec 2015 23:01:31 -0800 (PST) Subject: [cmake-developers] [CMake] How to set _default_ timeout for the ctest command? (fwd) In-Reply-To: References: Message-ID: On 2015-12-15 07:09+0100 Attila Krasznahorkay wrote: > Hi Alan, > > Are you just looking for the TIMEOUT property on the tests? Hi Attila: No. As I said in my post, I tried that test property but the problem was that absolutely fixed the timeout for the test so it could not be overriden by the ctest --timeout option. And similarly for every other way for a project to choose a timeout. On the cmake general list, Brad recently answered my original query on this subject and appears to agree with me that that ctest --timeout option should always have the highest priority, i.e., override any timeout set by the project such as the above TIMEOUT property. If the consensus continues to be that is the desired behaviour it appears some CMake/CTest code changes will be necessary to change to that behaviour. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From ben.boeckel at kitware.com Tue Dec 15 11:20:23 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 15 Dec 2015 11:20:23 -0500 Subject: [cmake-developers] [CMake] How to set _default_ timeout for the ctest command? (fwd) In-Reply-To: References: Message-ID: <20151215162023.GA28032@megas.khq.kitware.com> On Mon, Dec 14, 2015 at 23:01:31 -0800, Alan W. Irwin wrote: > On the cmake general list, Brad recently answered my original query on this > subject and appears to agree with me that that ctest --timeout > option should always have the highest priority, i.e., override any > timeout set by the project such as the above TIMEOUT property. If the > consensus continues to be that is the desired behaviour it appears > some CMake/CTest code changes will be necessary to change to that > behaviour. Hmm. I don't know. Some tests have timeouts set because they either *do* take that long or *shouldn't* take as long as the timeout (e.g., those that might deadlock). I think, instead, that --min-timeout and --max-timeout options might be better which allow you to say "this machine is slow; tests may take longer (max(property, option))" or "this machine is fast, clamp down the timeout (min(property, option))". Alternatively, a --timeout-scale option to multiply all timeouts in properties might be better. --Ben From DLRdave at aol.com Tue Dec 15 12:08:11 2015 From: DLRdave at aol.com (David Cole) Date: Tue, 15 Dec 2015 12:08:11 -0500 Subject: [cmake-developers] [CMake] How to set _default_ timeout for the ctest command? (fwd) In-Reply-To: <20151215162023.GA28032@megas.khq.kitware.com> References: <20151215162023.GA28032@megas.khq.kitware.com> Message-ID: Thanks, Ben. That was gonna be my 2 cents, too: If I set a test property to have a 1, 5 or 10 second timeout, then I want the test to timeout if it takes any longer than that. I do this on tests which must execute quickly even in a loaded CPU scenario. I would not want the global timeout to take precedence in this case and have my performance critical test taking much longer than it's supposed to, and then pass anyway with no timeout indication. More use cases to consider. Although I do agree, a command line specified option should take precedence over the global variable/property. (Just like the test's timeout property should take precedence over the global too: it's more local in scope, and should be preferred unless there's a **new** mechanism introduced to change the existing behavior.) D On Tue, Dec 15, 2015 at 11:20 AM, Ben Boeckel wrote: > On Mon, Dec 14, 2015 at 23:01:31 -0800, Alan W. Irwin wrote: >> On the cmake general list, Brad recently answered my original query on this >> subject and appears to agree with me that that ctest --timeout >> option should always have the highest priority, i.e., override any >> timeout set by the project such as the above TIMEOUT property. If the >> consensus continues to be that is the desired behaviour it appears >> some CMake/CTest code changes will be necessary to change to that >> behaviour. > > Hmm. I don't know. Some tests have timeouts set because they either *do* > take that long or *shouldn't* take as long as the timeout (e.g., those > that might deadlock). > > I think, instead, that --min-timeout and --max-timeout options might be > better which allow you to say "this machine is slow; tests may take > longer (max(property, option))" or "this machine is fast, clamp down the > timeout (min(property, option))". Alternatively, a --timeout-scale > option to multiply all timeouts in properties might be better. > > --Ben > -- > > 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 From irwin at beluga.phys.uvic.ca Tue Dec 15 13:33:38 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Tue, 15 Dec 2015 10:33:38 -0800 (PST) Subject: [cmake-developers] [CMake] How to set _default_ timeout for the ctest command? (fwd) In-Reply-To: <20151215162023.GA28032@megas.khq.kitware.com> References: <20151215162023.GA28032@megas.khq.kitware.com> Message-ID: On 2015-12-15 11:20-0500 Ben Boeckel wrote: > On Mon, Dec 14, 2015 at 23:01:31 -0800, Alan W. Irwin wrote: >> On the cmake general list, Brad recently answered my original query on this >> subject and appears to agree with me that that ctest --timeout >> option should always have the highest priority, i.e., override any >> timeout set by the project such as the above TIMEOUT property. If the >> consensus continues to be that is the desired behaviour it appears >> some CMake/CTest code changes will be necessary to change to that >> behaviour. > > Hmm. I don't know. Some tests have timeouts set because they either *do* > take that long or *shouldn't* take as long as the timeout (e.g., those > that might deadlock). That's fine. Projects should be able to set _default_ timeouts on individual tests or their entire set of tests in the most intelligent way they can think of. But ultimately the user should have the ability to override whatever value was set in case they have an extraordinarily slow or fast machine or there is a configuration possible on the project (the case I ran into with lapack where I promoted double precision to quadruple precision on an Intel box which must fall back to software emulation of quadruple precision) where all tests average much slower than normal. (The average slowdown factor is roughly 60 for the quadruple precision lapack tests.) > I think, instead, that --min-timeout and --max-timeout options might be > better which allow you to say "this machine is slow; tests may take > longer (max(property, option))" or "this machine is fast, clamp down the > timeout (min(property, option))". Alternatively, a --timeout-scale > option to multiply all timeouts in properties might be better. I think we are stuck with --timeout since it has been available as a ctest option for a long time. So the first priority is that option should override anything set by the project, i.e., anything set by the project should be considered to be a default value. That said, most cases including the ones I discussed above are scaling ones so I agree it would be worthwhile to implement an additional overriding --timeout-scale option for ctest which multiplies all default timeouts set by the project. If the user specifies both --timeout and --timeout-scale then one of them should be ignored in a well-documented way (probably --timeout since --timeout-scale is a bit more sophisticated). Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From ben.boeckel at kitware.com Tue Dec 15 13:53:04 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 15 Dec 2015 13:53:04 -0500 Subject: [cmake-developers] [CMake] How to set _default_ timeout for the ctest command? (fwd) In-Reply-To: References: <20151215162023.GA28032@megas.khq.kitware.com> Message-ID: <20151215185304.GA28843@megas.khq.kitware.com> On Tue, Dec 15, 2015 at 10:33:38 -0800, Alan W. Irwin wrote: > On 2015-12-15 11:20-0500 Ben Boeckel wrote: > > I think, instead, that --min-timeout and --max-timeout options might be > > better which allow you to say "this machine is slow; tests may take > > longer (max(property, option))" or "this machine is fast, clamp down the > > timeout (min(property, option))". Alternatively, a --timeout-scale > > option to multiply all timeouts in properties might be better. > > I think we are stuck with --timeout since it has been available as a > ctest option for a long time. So the first priority is that option > should override anything set by the project, i.e., anything set by > the project should be considered to be a default value. Changing --timeout's behavior isn't going to help you since old CMake versions won't work as intended. I don't think changing its behavior is best. For example, in our Buildbot infrastructure, we set the default timeout to 3 minutes because the default timeout for CTest causes tests to take *way* too long (I think it seems to be 25 minutes?). Some tests, however, *do* take longer than that on even reasonable hardware, so those should ignore the lower default timeout we set. Breaking this gets a *big* -1 from me. If you want compatibility between ctest versions, write a script to add arguments to a list based on the version that is running the script (any new command line arguments should get corresponding ctest_test() keywords). > That said, most cases including the ones I discussed above are scaling > ones so I agree it would be worthwhile to implement an additional > overriding --timeout-scale option for ctest which multiplies all > default timeouts set by the project. If the user specifies both > --timeout and --timeout-scale then one of them should be ignored in a > well-documented way (probably --timeout since --timeout-scale is a bit > more sophisticated). I think it would be "apply the scaling, but if there is no value, use the --timeout value". Whether that is pre- or post-scaling is arguable (one makes more sense reading, the other makes it easier to script). --Ben From irwin at beluga.phys.uvic.ca Tue Dec 15 14:36:33 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Tue, 15 Dec 2015 11:36:33 -0800 (PST) Subject: [cmake-developers] [CMake] How to set _default_ timeout for the ctest command? (fwd) In-Reply-To: <20151215185304.GA28843@megas.khq.kitware.com> References: <20151215162023.GA28032@megas.khq.kitware.com> <20151215185304.GA28843@megas.khq.kitware.com> Message-ID: On 2015-12-15 13:53-0500 Ben Boeckel wrote: > On Tue, Dec 15, 2015 at 10:33:38 -0800, Alan W. Irwin wrote: >> On 2015-12-15 11:20-0500 Ben Boeckel wrote: >>> I think, instead, that --min-timeout and --max-timeout options might be >>> better which allow you to say "this machine is slow; tests may take >>> longer (max(property, option))" or "this machine is fast, clamp down the >>> timeout (min(property, option))". Alternatively, a --timeout-scale >>> option to multiply all timeouts in properties might be better. >> >> I think we are stuck with --timeout since it has been available as a >> ctest option for a long time. So the first priority is that option >> should override anything set by the project, i.e., anything set by >> the project should be considered to be a default value. > > Changing --timeout's behavior isn't going to help you since old CMake > versions won't work as intended. I don't think changing its behavior is > best. For example, in our Buildbot infrastructure, we set the default > timeout to 3 minutes because the default timeout for CTest causes tests > to take *way* too long (I think it seems to be 25 minutes?). Some tests, > however, *do* take longer than that on even reasonable hardware, so > those should ignore the lower default timeout we set. Breaking this gets > a *big* -1 from me. There are a number of issues you have lumped together here. 1. Old versus new. We should plan the ideal timeout experience for the user here, and if we get that right once the modified version of --timeout and the proposed new --timeout-scale lands, then those having trouble with timeouts for old CMake/CTest versions can be referred to the new CMake/CTest version. 2. Global versus individual test timeouts set by the project. I believe we are all agreed here; individual project timeouts supersedes global project timeouts. The above considerations are orthogonal to my principal concern which is the user should have command-line freedom to supersede any timeout set by a project since it is usually impossible for the project to anticipate the user's timeout needs 100 per cent of the time. I think the --timeout-scale option you proposed which would multiply both a project's global and individual test timeouts would be a very nice way to implement this desired user freedom. So our disagreement really boils down to what to do with --timeout. It is obvious that is an extremely brute force option, but sometimes that is useful so I think it should be changed to take precedence (just like the proposed --timeout-scale) over both global and individual test timeouts set by the project. However, if you feel strongly for some reason that this option should have precedence over the global default set by the project but not over individual test timeouts set by the project, then I would be willing to go along with that so long as --timeout-scale is there to provide the desired user freedom and that departure in behaviour for --timeout for what happens with --timeout-scale was clearly documented. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From mishchea at gmail.com Tue Dec 15 23:20:29 2015 From: mishchea at gmail.com (Andrey Mishchenko) Date: Tue, 15 Dec 2015 23:20:29 -0500 Subject: [cmake-developers] Restriction on target types for GraphViz dependency graph generation Message-ID: Hi, I noticed that the automatic dependency graph generation in CMake targeting GraphViz only considers targets of certain types. In particular, it only adds nodes for executables and shared, static, and module libraries. Is this deliberate? If I submit a patch extending this functionality to (optionally, via configuration variables) work with more target types, would it be received well? Andrey Mishchenko -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Wed Dec 16 03:47:55 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 16 Dec 2015 03:47:55 -0500 Subject: [cmake-developers] [CMake 0015884]: 3.4.1 regression for vs2015 detection Message-ID: <5ea843369c92157666dcc47506230e0d@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15884 ====================================================================== Reported By: hume npx Assigned To: ====================================================================== Project: CMake Issue ID: 15884 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-12-16 03:47 EST Last Modified: 2015-12-16 03:47 EST ====================================================================== Summary: 3.4.1 regression for vs2015 detection Description: Visual Studio 14 2015 can not find CXX compiler, while the same env and command line for cmake 3.3.1 just worked Steps to Reproduce: with vs2015 update1 installed, make a simple cmake project and then cd build cmake ../src -- Building for: Visual Studio 14 2015 -- The C compiler identification is unknown -- The CXX compiler identification is unknown Additional Information: uninstall 3.4.1 and install cmake 3.3.1 just worked ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-12-16 03:47 hume npx New Issue ====================================================================== From attila.krasznahorkay at gmail.com Wed Dec 16 04:11:53 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Wed, 16 Dec 2015 10:11:53 +0100 Subject: [cmake-developers] Restriction on target types for GraphViz dependency graph generation In-Reply-To: References: Message-ID: Hi Andrey, I would be extremely happy with an extension to this functionality. Right now I have way too many targets in my projects to make good sense of them if all of them are put into a single graph. If I would be able to specify that I'd like to see the connections between all the targets with names ".*Pkg$" for instance, that could be very nice. Cheers, Attila > On 16 Dec 2015, at 05:20, Andrey Mishchenko wrote: > > Hi, > > I noticed that the automatic dependency graph generation in CMake targeting GraphViz only considers targets of certain types. In particular, it only adds nodes for executables and shared, static, and module libraries. > > Is this deliberate? > > If I submit a patch extending this functionality to (optionally, via configuration variables) work with more target types, would it be received well? > > Andrey Mishchenko > -- > > 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 From asn at cryptomilk.org Wed Dec 16 05:04:02 2015 From: asn at cryptomilk.org (Andreas Schneider) Date: Wed, 16 Dec 2015 11:04:02 +0100 Subject: [cmake-developers] [PATCH] Get the PYTHON_SITELIB directory in FindPythonLibs Message-ID: <3043654.lmNKNfrjzv@magrathea.cryptomilk.site> Hello, similar to what I implemented in FindPerlLibs.cmake some years ago, I've added PYTHON_SITELIB to FindPythonLibs. With PYTHON_SITELIB you have the location where to install the python modules you built with cmake. Example: find_package(PythonInterp) find_package(PythonLibs) python_add_module(my_py my_py.c) install(TARGETS my_py DESTINATION ${CMAKE_INSTALL_PREFIX}/${PYTHON_SITELIB}) Please review and push. Thanks. Cheers, -- andreas -- Andreas Schneider GPG-ID: CC014E3D www.cryptomilk.org asn at cryptomilk.org -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Modules-Add-variable-for-PYTHON_SITELIB-and-PYTHON_S.patch Type: text/x-patch Size: 2409 bytes Desc: not available URL: From mantis at public.kitware.com Wed Dec 16 05:22:19 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 16 Dec 2015 05:22:19 -0500 Subject: [cmake-developers] [CMake 0015885]: Ninja always relinks libraries that doesn't export any symbols (on Windows) Message-ID: <59d2b548afaeb54fda2ba580c34e670c@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15885 ====================================================================== Reported By: Pavel Solodovnikov Assigned To: ====================================================================== Project: CMake Issue ID: 15885 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-12-16 05:22 EST Last Modified: 2015-12-16 05:22 EST ====================================================================== Summary: Ninja always relinks libraries that doesn't export any symbols (on Windows) Description: Consider the following test case: CMakeLists.txt: cmake_minimum_required(VERSION 2.8) project(foo CXX) add_library(foo SHARED test.cpp) test.cpp: void foo() {} With such setup when I run cmake (cmake -G Ninja) and execute several consecutive builds, each time ninja relinks "foo" library. If test.cpp instead contains exported symbol, for example: __declspec( dllexport ) void foo(){} ninja works as expected, reporting for the second build "ninja: no work to do". The cause of the problem is that cmake generates link rule for "foo.dll" in such a way that it depends on "foo.lib" file existence: build foo.dll foo.lib: CXX_SHARED_LIBRARY_LINKER__foo CMakeFiles\foo.dir\test.cpp.obj If a library has no exported symbols, MSVC doesn't produce a ".lib" file for it during a build. Because of that ninja assumes it needs to relink again to produce import library for "foo.dll". Steps to Reproduce: 1) extract attached archive with test files (CMakeLists.txt and test.cpp). 2) run "cmake -G Ninja" 3) ninja (builds and links library) 4) ninja (should report "no work to do" but relinks the library again) Additional Information: It's a windows-specific case (more specifically Windows + MSVC, I assume, at least not tested with MinGW toolchain), does not occur on linux since there is no such thing as "import library" for shared libraries. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-12-16 05:22 Pavel SolodovnikovNew Issue 2015-12-16 05:22 Pavel SolodovnikovFile Added: cmake_relink_test.zip ====================================================================== From emilie.har at gmail.com Wed Dec 16 08:22:31 2015 From: emilie.har at gmail.com (Emilie) Date: Wed, 16 Dec 2015 14:22:31 +0100 Subject: [cmake-developers] Fix get_item_rpaths function: gp_append_unique for each rpath returned by "otool" command Message-ID: Hello, I attach a patch to fix the get_item_rpaths function (in BundleUtilities module). I had an error with fixup_bundle on osx: a rpath was added twice in the install_name_tool command for "delete_rpath". The command "otool" could return several rpath, so I call gp_append_unique for each rpath. Emilie -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_get_rpath.patch Type: application/octet-stream Size: 1034 bytes Desc: not available URL: From brad.king at kitware.com Thu Dec 17 11:12:13 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 17 Dec 2015 11:12:13 -0500 Subject: [cmake-developers] [PATCH] Get the PYTHON_SITELIB directory in FindPythonLibs In-Reply-To: <3043654.lmNKNfrjzv@magrathea.cryptomilk.site> References: <3043654.lmNKNfrjzv@magrathea.cryptomilk.site> Message-ID: <5672DEDD.4070903@kitware.com> On 12/16/2015 05:04 AM, Andreas Schneider wrote: > similar to what I implemented in FindPerlLibs.cmake some years ago, I've added > PYTHON_SITELIB to FindPythonLibs. With PYTHON_SITELIB you have the location > where to install the python modules you built with cmake. > > Example: > > find_package(PythonInterp) > find_package(PythonLibs) > > python_add_module(my_py my_py.c) > install(TARGETS my_py DESTINATION ${CMAKE_INSTALL_PREFIX}/${PYTHON_SITELIB}) One of the goals of FindPythonLibs is to work when cross-compiling such that one cannot run the interpreter natively. That is one reason we don't just ask the interpreter where to get the libraries. There has been some discussion about doing such lookups conditionally when we can run the interpreter but also having a fallback. If there is another way to get this information then please use it. Otherwise I'd rather not guarantee that we provide the information. Projects can always run the same execute_process call themselves. -Brad From brad.king at kitware.com Thu Dec 17 11:12:22 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 17 Dec 2015 11:12:22 -0500 Subject: [cmake-developers] [PATCH] CMakeParseArguments: Test suite and native implementation In-Reply-To: References: Message-ID: <5672DEE6.9050503@kitware.com> On 12/14/2015 04:52 PM, Matthias M?nnich wrote: > This adds a test suite for the CMakeParseArguments module. In addition > the second change implements cmake_parse_arguments(...) as native > command. Thanks! Applied with minor tweaks: CMakeParseArguments: add a RunCMake test suite https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cbbdfc2b CMakeParseArguments: replace by native cmake_parse_arguments command https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e8b14831 cmake_parse_arguments: consider duplicate keyword as warning https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ab8a2808 and merged to 'next' for testing. -Brad From brad.king at kitware.com Thu Dec 17 11:12:27 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 17 Dec 2015 11:12:27 -0500 Subject: [cmake-developers] Fix get_item_rpaths function: gp_append_unique for each rpath returned by "otool" command In-Reply-To: References: Message-ID: <5672DEEB.3050505@kitware.com> On 12/16/2015 08:22 AM, Emilie wrote: > I attach a patch to fix the get_item_rpaths function Thanks, applied: BundleUtilities: Fix handling of multiple RPATHs from OS X otool https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a479d7a0 -Brad From asn at cryptomilk.org Thu Dec 17 11:39:04 2015 From: asn at cryptomilk.org (Andreas Schneider) Date: Thu, 17 Dec 2015 17:39:04 +0100 Subject: [cmake-developers] [PATCH] Get the PYTHON_SITELIB directory in FindPythonLibs In-Reply-To: <5672DEDD.4070903@kitware.com> References: <3043654.lmNKNfrjzv@magrathea.cryptomilk.site> <5672DEDD.4070903@kitware.com> Message-ID: <1729917.XrOEer3Thy@magrathea.cryptomilk.site> On Thursday 17 December 2015 11:12:13 Brad King wrote: > On 12/16/2015 05:04 AM, Andreas Schneider wrote: > > similar to what I implemented in FindPerlLibs.cmake some years ago, I've > > added PYTHON_SITELIB to FindPythonLibs. With PYTHON_SITELIB you have the > > location where to install the python modules you built with cmake. > > > > Example: > > > > find_package(PythonInterp) > > find_package(PythonLibs) > > > > python_add_module(my_py my_py.c) > > install(TARGETS my_py DESTINATION > > ${CMAKE_INSTALL_PREFIX}/${PYTHON_SITELIB}) > One of the goals of FindPythonLibs is to work when cross-compiling such > that one cannot run the interpreter natively. That is one reason we > don't just ask the interpreter where to get the libraries. There has > been some discussion about doing such lookups conditionally when we > can run the interpreter but also having a fallback. If you look at the code, my changes to the code are inside an already existing if (PYTHON_EXECUTABLE) ... So if you don't call find_package(PythonInterp) before find_package(PythonLibs) it will not get the PATH information for PYTHON_SITELIB. The behavior of the module doesn't not change with this addition! As it seems you did not look with enough context at the patch you can view the changes with more context (40 lines) here: https://git.cryptomilk.org/users/asn/cmake.git/commit/?h=asn_pythonlibs&id=e414ea43caedeffeb27bb367b5f6c41e6238052a&context=40&ignorews=0&dt=0 Cheers, -- andreas -- Andreas Schneider GPG-ID: CC014E3D www.cryptomilk.org asn at cryptomilk.org From mantis at public.kitware.com Thu Dec 17 12:14:01 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 17 Dec 2015 12:14:01 -0500 Subject: [cmake-developers] [CMake 0015886]: FindHTMLHelp.cmake doesn't set HTMLHelp_FOUND variable Message-ID: <5b130e035397acb948cbed1a94b62ae9@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15886 ====================================================================== Reported By: grahamb Assigned To: ====================================================================== Project: CMake Issue ID: 15886 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-12-17 12:14 EST Last Modified: 2015-12-17 12:14 EST ====================================================================== Summary: FindHTMLHelp.cmake doesn't set HTMLHelp_FOUND variable Description: The module doesn't set the corresponding package HTMLHelp_FOUND variable. This leads to erroneous reports that the package has not been found when using FEATURE_SUMMARY Steps to Reproduce: With this file: cmake_minimum_required(VERSION 3.0) set(CMAKE_FIND_LIBRARY_PREFIXES "") set(CMAKE_FIND_LIBRARY_SUFFIXES "") include(FeatureSummary) find_package(HTMLHelp) message(STATUS "HTML Help Compiler: ${HTML_HELP_COMPILER}") feature_summary(WHAT ALL) The output of CMake -P is: -- HTML Help Compiler: C:/Program Files (x86)/HTML Help Workshop/hhc.exe -- -- The following OPTIONAL packages have not been found: * HTMLHelp Additional Information: Should the FOUND variable be dependent on the INCLUDE and LIBRARY? Not sure. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-12-17 12:14 grahamb New Issue ====================================================================== From ben.boeckel at kitware.com Thu Dec 17 12:53:41 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 17 Dec 2015 12:53:41 -0500 Subject: [cmake-developers] [CMake] How to set _default_ timeout for the ctest command? (fwd) In-Reply-To: References: Message-ID: <20151217175341.GB10246@megas.khq.kitware.com> On Mon, Dec 14, 2015 at 23:01:31 -0800, Alan W. Irwin wrote: > On the cmake general list, Brad recently answered my original query on this > subject and appears to agree with me that that ctest --timeout > option should always have the highest priority, i.e., override any > timeout set by the project such as the above TIMEOUT property. Here's the snippet from Brad's message: > From the history of that code it looks like --timeout was added with > no consideration of its relationship to CTEST_TEST_TIMEOUT. Some > other CTest options in the same scope as CTEST_TEST_TIMEOUT can be > overridden by the command line, so I agree that --timeout should > override it too. http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/54086/focus=54168 which implies that --timeout sets CTEST_TEST_TIMEOUT, but any properties would ignore the setting (as they do now). --Ben From brad.king at kitware.com Thu Dec 17 13:25:54 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 17 Dec 2015 13:25:54 -0500 Subject: [cmake-developers] [PATCH] Get the PYTHON_SITELIB directory in FindPythonLibs In-Reply-To: <1729917.XrOEer3Thy@magrathea.cryptomilk.site> References: <3043654.lmNKNfrjzv@magrathea.cryptomilk.site> <5672DEDD.4070903@kitware.com> <1729917.XrOEer3Thy@magrathea.cryptomilk.site> Message-ID: <5672FE32.8060907@kitware.com> On 12/17/2015 11:39 AM, Andreas Schneider wrote: > If you look at the code, my changes to the code are inside an already existing > > if (PYTHON_EXECUTABLE) > ... > > So if you don't call find_package(PythonInterp) before > find_package(PythonLibs) it will not get the PATH information for > PYTHON_SITELIB. Sure, but if PYTHON_EXECUTABLE is set to refer to a binary that cannot run on the host because it is part of a cross-compiling SDK then this won't work. Or, if PYTHON_EXECUTABLE can run on the host but it is not the executable that corresponds to the libraries because the libs are for another architecture then it will give wrong information. -Brad From DLRdave at aol.com Thu Dec 17 13:54:08 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 17 Dec 2015 13:54:08 -0500 Subject: [cmake-developers] [CMake] How to set _default_ timeout for the ctest command? (fwd) In-Reply-To: <20151217175341.GB10246@megas.khq.kitware.com> References: <20151217175341.GB10246@megas.khq.kitware.com> Message-ID: I agree with Brad, the --timeout command line parameter should only set/override the variable CTEST_TEST_TIMEOUT. The behavior w.r.t. test TIMEOUT properties should be left as is for this change. A **new** --timeout-scale with well defined / documented interactions with the global variable and the test properties would be the best approach for introducing changes in behavior. Or a **new** --ignore-timeout-test-property to simply use the global value everywhere for some use cases. D On Thu, Dec 17, 2015 at 12:53 PM, Ben Boeckel wrote: > On Mon, Dec 14, 2015 at 23:01:31 -0800, Alan W. Irwin wrote: >> On the cmake general list, Brad recently answered my original query on this >> subject and appears to agree with me that that ctest --timeout >> option should always have the highest priority, i.e., override any >> timeout set by the project such as the above TIMEOUT property. > > Here's the snippet from Brad's message: > >> From the history of that code it looks like --timeout was added with >> no consideration of its relationship to CTEST_TEST_TIMEOUT. Some >> other CTest options in the same scope as CTEST_TEST_TIMEOUT can be >> overridden by the command line, so I agree that --timeout should >> override it too. > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/54086/focus=54168 > > which implies that --timeout sets CTEST_TEST_TIMEOUT, but any properties > would ignore the setting (as they do now). > > --Ben > -- > > 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 From ben.boeckel at kitware.com Thu Dec 17 14:42:05 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 17 Dec 2015 14:42:05 -0500 Subject: [cmake-developers] [CMake] How to set _default_ timeout for the ctest command? (fwd) In-Reply-To: References: <20151217175341.GB10246@megas.khq.kitware.com> Message-ID: <20151217194205.GB18935@megas.khq.kitware.com> On Thu, Dec 17, 2015 at 13:54:08 -0500, David Cole wrote: > I agree with Brad, the --timeout command line parameter should only > set/override the variable CTEST_TEST_TIMEOUT. The behavior w.r.t. test > TIMEOUT properties should be left as is for this change. This behavior also makes sense to me. However, what about script mode which sets CTEST_TEST_TIMEOUT itself? Is CTEST_TEST_TIMEOUT readonly if --timeout is given? --Ben From neundorf at kde.org Thu Dec 17 15:52:34 2015 From: neundorf at kde.org (Alexander Neundorf) Date: Thu, 17 Dec 2015 21:52:34 +0100 Subject: [cmake-developers] [PATCH] CMakeParseArguments: Test suite and native implementation In-Reply-To: <5672DEE6.9050503@kitware.com> References: <5672DEE6.9050503@kitware.com> Message-ID: <2401555.CjxhUemo9T@tuxedo.neundorf.net> On Thursday, December 17, 2015 11:12:22 Brad King wrote: > On 12/14/2015 04:52 PM, Matthias M?nnich wrote: > > This adds a test suite for the CMakeParseArguments module. In addition > > the second change implements cmake_parse_arguments(...) as native > > command. > > Thanks! Applied with minor tweaks: Cool :-) Faster and one module less to load and care about :-) Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From rleigh at codelibre.net Thu Dec 17 18:05:38 2015 From: rleigh at codelibre.net (Roger Leigh) Date: Thu, 17 Dec 2015 23:05:38 +0000 Subject: [cmake-developers] [PATCH] FindBoost: Boost 1.60 support Message-ID: <56733FC2.9050909@codelibre.net> With the release of Boost 1.60, I've updated FindBoost to work with this version. Pushed to https://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/boost-1.60 and merged into next for review. - Adds 1.60.0 and 1.60 as valid versions - Adds dependency information for 1.60; this is the same as for 1.59 except that for "set(_Boost_LOG_DEPENDENCIES date_time log_setup ..." the date_time and log_setup dependencies were swapped. I don't think this will make any difference, but including it to be on the safe side (it's harmless). I have tested on Ubuntu 15.10 and Windows with VS2013, with projects using FindBoost against a locally compiled Boost 1.60. They found Boost 1.60 and its components, and compiled and linked and passed their unit tests. Regards, Roger From irwin at beluga.phys.uvic.ca Thu Dec 17 18:38:09 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 17 Dec 2015 15:38:09 -0800 (PST) Subject: [cmake-developers] [CMake] How to set _default_ timeout for the ctest command? (fwd) In-Reply-To: References: <20151217175341.GB10246@megas.khq.kitware.com> Message-ID: On 2015-12-17 13:54-0500 David Cole wrote: > I agree with Brad, the --timeout command line parameter should only > set/override the variable CTEST_TEST_TIMEOUT. The behavior w.r.t. test > TIMEOUT properties should be left as is for this change. > > A **new** --timeout-scale with well defined / documented interactions > with the global variable and the test properties would be the best > approach for introducing changes in behavior. Or a **new** > --ignore-timeout-test-property to simply use the global value > everywhere for some use cases. This seems like a reasonable approach to me to get these timeout issues addressed. However, to be clear, here are the consequences for a project like lapack where some extrordinary but legitimate timing variations can occur. 1. The current advice to such projects would be to rigourously avoid setting either CTEST_TEST_TIMEOUT or individual test timeout properties since the user currently has no control over those (which illustrates why addressing the above issues is important). 2. Once the --timeout fix that allows it to override CTEST_TEST_TIMEOUT set by the project has become part of a release, AND when that version of cmake is the minimum allowed by the project, then it will be safe for the project to start using CTEST_TEST_TIMEOUT since that value can now be overridden by the user with the --timeout option. But the project should still rigourously avoid using individual timeout properties until the conditions listed in 3. are true. 3. Once the implementation of the proposed new --timeout-scale option has been implemented and become part of a release, AND when that version of cmake is the minimum allowed by the project, then it will be safe for such projects to set both CTEST_TEST_TIMEOUT and individual timeout properties since the user now has full control over all such project timeouts. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From DLRdave at aol.com Thu Dec 17 21:39:55 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 17 Dec 2015 21:39:55 -0500 Subject: [cmake-developers] [CMake] How to set _default_ timeout for the ctest command? (fwd) In-Reply-To: <20151217194205.GB18935@megas.khq.kitware.com> References: <20151217175341.GB10246@megas.khq.kitware.com> <20151217194205.GB18935@megas.khq.kitware.com> Message-ID: The principle "most local setting wins" should be followed. If a script is called without --timeout cmd line param, CTEST_TEST_TIMEOUT applies, if set. Otherwise default timeout value. If a script is called with --timeout cmd line param, then that **is** the timeout value, and CTEST_TEST_TIMEOUT should be ignored. In either case, test property TIMEOUT should win/override to preserve the backwards compatibility for the use cases which currently depend on that. Good scripts will wrap their setting of CTEST_TEST_TIMEOUT with an "if(NOT DEFINED" anyhow... Same with good projects. David > On Dec 17, 2015, at 2:42 PM, Ben Boeckel wrote: > >> On Thu, Dec 17, 2015 at 13:54:08 -0500, David Cole wrote: >> I agree with Brad, the --timeout command line parameter should only >> set/override the variable CTEST_TEST_TIMEOUT. The behavior w.r.t. test >> TIMEOUT properties should be left as is for this change. > > This behavior also makes sense to me. However, what about script mode > which sets CTEST_TEST_TIMEOUT itself? Is CTEST_TEST_TIMEOUT readonly if > --timeout is given? > > --Ben From DLRdave at aol.com Thu Dec 17 21:45:34 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 17 Dec 2015 21:45:34 -0500 Subject: [cmake-developers] [CMake] How to set _default_ timeout for the ctest command? (fwd) In-Reply-To: References: <20151217175341.GB10246@megas.khq.kitware.com> Message-ID: Sounds to me like lapack should conditionally set CTEST_TEST_TIMEOUT only if it's not DEFINED already. With such code in the project, callers could define it on the command line with -D, or directly in a ctest -S script, and the passed in vale would "win" since in this case, the project would NOT set its default value. Pretty standard to do "set only if not set" for variables that callers might potentially want to override in a ctest script or in a CMakeLists file. This works with existing recent versions of cmake and ctest just fine... I think ctest has supported -D cmd line params since 3.0 or so. David > On Dec 17, 2015, at 6:38 PM, Alan W. Irwin wrote: > >> On 2015-12-17 13:54-0500 David Cole wrote: >> >> I agree with Brad, the --timeout command line parameter should only >> set/override the variable CTEST_TEST_TIMEOUT. The behavior w.r.t. test >> TIMEOUT properties should be left as is for this change. >> >> A **new** --timeout-scale with well defined / documented interactions >> with the global variable and the test properties would be the best >> approach for introducing changes in behavior. Or a **new** >> --ignore-timeout-test-property to simply use the global value >> everywhere for some use cases. > > This seems like a reasonable approach to me to get these timeout issues > addressed. > > However, to be clear, here are the consequences for a project like > lapack where some extrordinary but legitimate timing variations can occur. > > 1. The current advice to such projects would be to rigourously avoid setting either > CTEST_TEST_TIMEOUT or individual test timeout properties since the user currently > has no control over those (which illustrates why addressing the above > issues is important). > > 2. Once the --timeout fix that allows it to override > CTEST_TEST_TIMEOUT set by the project has become part of a release, > AND when that version of cmake is the minimum allowed by the project, > then it will be safe for the project to start using CTEST_TEST_TIMEOUT > since that value can now be overridden by the user with the --timeout > option. But the project should still rigourously avoid using > individual timeout properties until the conditions listed in 3. are > true. > > 3. Once the implementation of the proposed new --timeout-scale option > has been implemented and become part of a release, AND when that > version of cmake is the minimum allowed by the project, then it will > be safe for such projects to set both CTEST_TEST_TIMEOUT and > individual timeout properties since the user now has full control > over all such project timeouts. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ From orion at cora.nwra.com Thu Dec 17 22:05:26 2015 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 17 Dec 2015 20:05:26 -0700 Subject: [cmake-developers] parallel install of different cmake versions In-Reply-To: <566ED558.5030402@kitware.com> References: <566B5F4D.1030701@cora.nwra.com> <566ED558.5030402@kitware.com> Message-ID: <567377F6.1040705@cora.nwra.com> On 12/14/2015 07:42 AM, Brad King wrote: > On 12/11/2015 06:42 PM, Orion Poplawski wrote: >> For Fedora EPEL we often end up packaging newer versions of cmake as cmakeXY >> (e.g. cmake34) that can be installed in parallel with the system cmake. This >> is a fairly invasive process. I'm attaching the current patch I'm working on >> for this. Is there any interest in cmake itself for supporting this kind of >> thing? > > Not particularly. That does look pretty invasive. > > Why not just install it to /usr/lib/cmake34 with normal names and symlink > the versioned names? E.g. > > /usr/bin/cmake34 -> /usr/lib/cmake34/bin/cmake > /usr/bin/ctest34 -> /usr/lib/cmake34/bin/ctest > ... > > I have many different CMake versions installed on my system in different > directories and use aliases or symlinks to reference them without being > in my PATH directly. > > -Brad > I'm not sure this would work. There seems to be many places in the code (some of which the patch addresses) where it calls executes "cmake" or "ctest" regardless of the name it was called with. If /usr/lib/cmake34/bin was not in the path (which would be the case with our EPEL packages unless we did more configuration) it would then end up calling the system cmake/ctest/etc. This sounds like a recipe for disaster. Or does cmake/ctest modify PATH internally? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From orion at cora.nwra.com Thu Dec 17 22:16:46 2015 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 17 Dec 2015 20:16:46 -0700 Subject: [cmake-developers] parallel install of different cmake versions In-Reply-To: References: <566B5F4D.1030701@cora.nwra.com> <566ED558.5030402@kitware.com> Message-ID: <56737A9E.9030902@cora.nwra.com> On 12/14/2015 08:56 AM, Eric Noulard wrote: > > > 2015-12-14 15:42 GMT+01:00 Brad King >: > > On 12/11/2015 06:42 PM, Orion Poplawski wrote: > > For Fedora EPEL we often end up packaging newer versions of cmake as cmakeXY > > (e.g. cmake34) that can be installed in parallel with the system cmake. This > > is a fairly invasive process. I'm attaching the current patch I'm working on > > for this. Is there any interest in cmake itself for supporting this kind of > > thing? > > Not particularly. That does look pretty invasive. > > Why not just install it to /usr/lib/cmake34 with normal names and > symlink > the versioned names? E.g. > > /usr/bin/cmake34 -> /usr/lib/cmake34/bin/cmake > /usr/bin/ctest34 -> /usr/lib/cmake34/bin/ctest > > > > +1 > Personnally when I installed several version of CMake I do install them > with a particular prefix and then I use update-alternatives(1) to install > proper symlinks to the specific location. > > I switch from one version to another using update-alternatives(1). > > This can certainly be used on Fedora/EPEL as well: > https://fedoraproject.org/wiki/Packaging:Alternatives Yes, but this cannot be done in rpm spec files for building other packages (as would be done in EPEL). Perhaps we could leverage environment-modules, but this would be a bit of a departure. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From brad.king at kitware.com Fri Dec 18 08:22:15 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 18 Dec 2015 08:22:15 -0500 Subject: [cmake-developers] parallel install of different cmake versions In-Reply-To: <567377F6.1040705@cora.nwra.com> References: <566B5F4D.1030701@cora.nwra.com> <566ED558.5030402@kitware.com> <567377F6.1040705@cora.nwra.com> Message-ID: <56740887.6050302@kitware.com> On 12/17/2015 10:05 PM, Orion Poplawski wrote: > I'm not sure this would work. There seems to be many places in the code > (some of which the patch addresses) where it calls executes "cmake" or > "ctest" regardless of the name it was called with. AFAIK those all use an absolute path. We don't depend on finding ourself in the PATH. I frequently run "cmake" via an absolute path without any "cmake" in the PATH. I also frequently run "cmake" via an alias of a different name with a different version of "cmake" in the PATH. If you find places where this is not true then we can fix those, but I run cmake this way every day since I keep so many versions around for testing. -Brad From Bartosz.Kosiorek at tomtom.com Fri Dec 18 10:46:06 2015 From: Bartosz.Kosiorek at tomtom.com (Bartosz Kosiorek) Date: Fri, 18 Dec 2015 15:46:06 +0000 Subject: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle. In-Reply-To: <566BB545.3090701@yahoo.com> References: <1449759153039.51334@tomtom.com> <1813369686.65723125.1449847446080.JavaMail.zimbra@elemtech.com> <1449853301422.90915@tomtom.com> <2780526.IlfGfMxfeF@stryke> <910432174.66323078.1449861684460.JavaMail.zimbra@elemtech.com> <1449866813173.56940@tomtom.com> <566B712B.6060503@yahoo.com> <1449889708273.6810@tomtom.com> <566BB545.3090701@yahoo.com> Message-ID: <1450453565837.62019@tomtom.com> Thank you all for your tips/advice. From our experience IDE generators (eg. Visual Studio, Xcode) is much slower than Make or Ninja. I will attach benchmarks later. Unfortunately I'm unable to build Universal libraries for x86 and arm architectures by using Makefile. See attached logs. It seems that two different SDK's (iPhoneOS and iPhoneSimulator) needs to be used in that case. Do you know how it could be fixed? Maybe I should add "CMAKE_OSX_SYSROOT "iphoneos" support for other generators? What do you think about that idea? Thanks in advance Bartosz? PS I'm attaching the script which I'm using for testing purposes. To reproduce it just run command (from command line): cd builddir && cmake .. && cmake --build . From: Ruslan Baratov [mailto:ruslan_baratov at yahoo.com] Sent: Saturday, December 12, 2015 6:49 AM To: Bartosz Kosiorek Cc: Clinton Stimpson; Gregor Jasny; CMake Developers Subject: Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle. On 12-Dec-15 10:08, Bartosz Kosiorek wrote: Thanks Ruslan. I would like to create instruction which is universal for all generators. I think it's not possible. E.g. IOS_INSTALL_COMBINED will work only for Xcode. Currently we would like to support both Make/Ninja and Xcode generators, ... because Make is much faster than Xcode generator, and we are using it in our CI system. Do you mean generate step or build? I've used to compile quite big projects like OpenCV with Xcode and according to the `top` it uses all my cores with clang++ at 100% CPU time. Can you show any benchmarks? Also note that Xcode can add some additional stuff, like dSYM: https://github.com/headupinclouds/gatherer/pull/69 Make is also common for other architectures (Linux, QNX, Android etc.) Unfortunately set(CMAKE_OSX_SYSROOT "iphoneos") is not working for me. It displays error: /Users/warsaw/Perforce/cmake-dev/cmake-build/bin/cmake .. && /Users/warsaw/Perforce/cmake-dev/cmake-build/bin/cmake --build . -- Configuring done -- Generating done -- Build files have been written to: /Users/warsaw/Perforce/cmake_ios_framework_with_resource2/builddir [ 14%] Building C object shared_empty/heymath/CMakeFiles/heymath.dir/add.c.o clang: warning: no such sysroot directory: 'iphoneos' ... Do you have some tip for that? Yes, this hint was for Xcode generator. After removing "-isysroot ${CMAKE_OSX_SYSROOT}" everything works perfectly. Thanks Unfortunately CMAKE_XCODE_ATTRIBUTE_IPHONEOS_DEPLOYMENT_TARGET is not working with Make. Is it possible to introduce CMAKE_IOS_DEPLOYMENT_TARGET, as we already have CMAKE_OSX_DEPLOYMENT_TARGET? Since OSX_ARCHITECTURES controls iOS architectures too I think request should sounds like "Extend OSX_DEPLOYMENT_TARGET property for iOS platform". I have attached my example script which I'm using. ?Could you please modify it to be better (and still support other generators)? I don't know how to use iOS target with Makefile generator. Some notes about project you've sent: * You need to add instructions to codesign your bundle * Instead of hardcoding `set(CMAKE_OSX_SYSROOT "/Applications/Xcode.app/.../iPhoneSimulator.sdk")` you can run `xcode-select -print-path` to detect location of default Xcode version * Should be `set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mios-version-min=8.0")` instead of `set(CMAKE_CXX_FLAGS "-mios-version-min=8.0")` otherwise some flags may be lost Ruslan Best Regards Bartosz ________________________________ From: Ruslan Baratov Sent: Saturday, December 12, 2015 1:58 AM To: Bartosz Kosiorek Cc: clinton at elemtech.com; Gregor Jasny; CMake Developers Subject: Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle. On 12-Dec-15 03:46, Bartosz Kosiorek wrote: Hi To enable iOS build, I'm using following settings in CMakeLists.txt: set(APPLE_PLATFORM "iphonesimulator") I think this one not needed. Can't find any place where it parsed. set(CMAKE_OSX_SYSROOT "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk") Can be set to: set(CMAKE_OSX_SYSROOT "iphoneos") in this case will support both simulator and device set(CMAKE_C_FLAGS "-isysroot ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0") set(CMAKE_CXX_FLAGS "-isysroot ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0") You can set minimum version by CMAKE_XCODE_ATTRIBUTE_IPHONEOS_DEPLOYMENT_TARGET variable. In case of `CMAKE_OSX_SYSROOT` variable is set to `iphoneos` option `-isysroot` is redundant. Do you think it should be documented? Where is the good place to do so? Maybe somewhere here: https://cmake.org/cmake/help/v3.4/variable/CMAKE_OSX_SYSROOT.html What do you think? ? ________________________________ From: clinton at elemtech.com Sent: Friday, December 11, 2015 8:21 PM To: Bartosz Kosiorek Cc: Bartosz Kosiorek; cmake-developers; Gregor Jasny Subject: Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle. ----- On Dec 11, 2015, at 11:44 AM, Bartosz Kosiorek wrote: Hi Because there is difference between OS X and iOS Bundles directory structure (see: Apple specification https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html), in trunk (In CMake 3.5) RESOURCE property create corresponding directory structure. I have already fix that with: https://public.kitware.com/Bug/view.php?id=15848 Ok. I hadn't been following all your work. Also, I didn't see a toggle in the CMake code you sent to choose an iOS bundle instead of OS X bundles. How is that toggled? So RESOURCE gives you a level of abstraction: For OSX: it will create "Resource" directory For iOS it will create "flat" directory structure. In your example "Resource" directory will be created in both cases (for OSX and iOS). Which is wrong: For OSX: it should create "Resource" directory For iOS it will create "flat" directory structure. I could provide patch to fix that issue, if you agree with that. What do you think about that? Do you think the same should be applied to "Headers"? I think the abstraction seems reasonable, as well as what you are proposing. However, I'm not an Apple guru. I wonder if there are other Apple experts that can weigh in this if better feedback is needed. Clint Best Regards Bartosz 2015-12-11 19:06 GMT+01:00 Clinton Stimpson >: On Friday, December 11, 2015 05:01:41 PM Bartosz Kosiorek wrote: > Thanks Clint > > Unfortunately MACOSX_PACKAGE_LOCATION is not working correctly with RESOURCE > property. For every resource which is marked as RESOURCE, will be placed in > root "Resources" directory. > > The CMake code below create following directory structure for OS X: > > ?? mul.framework > ??? Headers -> Versions/Current/Headers > ??? Resources -> Versions/Current/Resources > ??? Versions > ? ??? A > ? ? ??? Headers > ? ? ? ??? mul.h > ? ? ??? Modules > ? ? ? ??? module.modulemap > ? ? ??? Resources > ? ? ? ??? Info.plist > ? ? ? ??? mulres.txt > ? ? ? ??? pl.txt > ? ? ? ??? resourcefile.txt > ? ? ??? lang > ? ? ? ??? en.txt > ? ? ??? mul > ? ??? Current -> A > ??? mul -> Versions/Current/mul > > > As you can see eveything which is marked as "RESOURCE" will be placed in > Versions/A/ directory My expectation will be that lang/pl.txt and > lang/en.txt should be in Resources/lang/ directory. Here is complete > directory structure: > > ?? mul.framework > ??? Headers -> Versions/Current/Headers > ??? Resources -> Versions/Current/Resources > ??? Versions > ? ??? A > ? ? ??? Headers > ? ? ? ??? mul.h > ? ? ??? Modules > ? ? ? ??? module.modulemap > ? ? ??? Resources > ? ? ? ??? Info.plist > ? ? ? ??? mulres.txt > ? ? ? ??? lang > ? ? ? ? ??? pl.txt > ? ? ? ? ??? en.txt > ? ? ? ??? resourcefile.txt > ? ? ??? lang > ? ? ? ??? en.txt > ? ? ??? mul > ? ??? Current -> A > ??? mul -> Versions/Current/mul > > > What do you think about that? > > Here is the source code: > > set_property(SOURCE module.modulemap > PROPERTY MACOSX_PACKAGE_LOCATION "Modules") > > set_property( > SOURCE lang/en.txt lang/pl.txt > PROPERTY MACOSX_PACKAGE_LOCATION "lang") > > set(RESLIST > mulres.txt > lang/pl.txt > resourcefile.txt > ) > > add_library(mul SHARED > mul.c > mul.h > module.modulemap > lang/pl.txt > lang/en.txt > resourcefile.txt > mulres.txt) > > # Create an iOS Framework bundle > set_target_properties(mul PROPERTIES > FRAMEWORK TRUE > MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul > MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 > MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 > XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" > PUBLIC_HEADER mul.h > RESOURCE "${RESLIST}" > ) Here is a CMakeLists.txt that will give you the desired layout. I also see that MACOSX_PACKAGE_LOCATION doesn't work with RESOURCE. set_property(SOURCE module.modulemap PROPERTY MACOSX_PACKAGE_LOCATION "Modules") set_property( SOURCE lang/pl.txt lang/en.txt PROPERTY MACOSX_PACKAGE_LOCATION "Resources/lang") set(RESLIST mulres.txt resourcefile.txt ) add_library(mul SHARED mul.c mul.h module.modulemap lang/pl.txt lang/en.txt resourcefile.txt mulres.txt) # Create an iOS Framework bundle set_target_properties(mul PROPERTIES FRAMEWORK TRUE MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" PUBLIC_HEADER mul.h RESOURCE "${RESLIST}" ) Now I'm wondering what does the RESOURCE target property do that MACOSX_PACKAGE_LOCATION doesn't already support? Clint -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: buildlogs.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake_ios_framework_with_resource3.zip Type: application/zip Size: 22258 bytes Desc: cmake_ios_framework_with_resource3.zip URL: From brad.king at kitware.com Fri Dec 18 11:06:36 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 18 Dec 2015 11:06:36 -0500 Subject: [cmake-developers] [PATCH] FindBoost: Boost 1.60 support In-Reply-To: <56733FC2.9050909@codelibre.net> References: <56733FC2.9050909@codelibre.net> Message-ID: <56742F0C.5020600@kitware.com> On 12/17/2015 06:05 PM, Roger Leigh wrote: > With the release of Boost 1.60, I've updated FindBoost to work with this > version. > > Pushed to > https://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/boost-1.60 > and merged into next for review. Looks good, thanks! -Brad From irwin at beluga.phys.uvic.ca Fri Dec 18 15:10:22 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Fri, 18 Dec 2015 12:10:22 -0800 (PST) Subject: [cmake-developers] parallel install of different cmake versions In-Reply-To: <56737A9E.9030902@cora.nwra.com> References: <566B5F4D.1030701@cora.nwra.com> <566ED558.5030402@kitware.com> <56737A9E.9030902@cora.nwra.com> Message-ID: On 2015-12-17 20:16-0700 Orion Poplawski wrote: > On 12/14/2015 08:56 AM, Eric Noulard wrote: >> +1 >> Personnally when I installed several version of CMake I do install them >> with a particular prefix and then I use update-alternatives(1) to install >> proper symlinks to the specific location. >> >> I switch from one version to another using update-alternatives(1). >> >> This can certainly be used on Fedora/EPEL as well: >> https://fedoraproject.org/wiki/Packaging:Alternatives > Hi Orion: I don't have any Fedora or rpm expertise to add, but like Brad I use multiple versions of cmake all the time without cross-talk between them. In my case I just install them with a separate installation prefix, and put the cmake version that I want on my PATH. I have investigated further what is installed in one of those prefixes. For CMake-3.3.2, most files are installed under $PREFIX/doc/cmake-3.3 and $PREFIX/share/cmake-3.3 so (subject to potential renaming to new locations by the cmake specfile) there is no chance of the installation of these files to clash between cmake major versions. That leaves a small number of additional files which are not identified by "cmake-3.3" in their pathname which are installed with the following names: $PREFIX/share/applications/CMake.desktop $PREFIX/share/icons/hicolor/32x32/apps/CMakeSetup.png $PREFIX/share/icons/hicolor/128x128/apps/CMakeSetup.png $PREFIX/share/mime/packages/cmakecache.xml $PREFIX/share/aclocal/cmake.m4 $PREFIX/bin/ccmake $PREFIX/bin/cmake $PREFIX/bin/cpack $PREFIX/bin/ctest $PREFIX/bin/cmake-gui So the cmake specfile would likely have to do something special with the first 5 of these files to avoid clashes, and the final 5 executables would have to be handled using the alternatives mechanism that is explained in the above URL given to you by Eric. > Yes, but this cannot be done in rpm spec files for building other packages > (as would be done in EPEL). Perhaps we could leverage environment-modules, > but this would be a bit of a departure. I don't understand this remark. If Fedora has already packaged multiple non-clashing versions of cmake as above, then surely all you have to do as a specfile maintainer of a given package that uses a specific major version of CMake to build the package is to have the specfile run a script before the build that runs update-alternatives (or whatever the equivalent name of that Debian application is on Fedora) to select the major CMake version that is required for the package build? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From mantis at public.kitware.com Fri Dec 18 19:44:04 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 18 Dec 2015 19:44:04 -0500 Subject: [cmake-developers] [CMake 0015887]: FindOpenssl can't find self built openssl but prefers slproweb openssl Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15887 ====================================================================== Reported By: Patrick Spendrin Assigned To: ====================================================================== Project: CMake Issue ID: 15887 Category: Modules Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-12-18 19:44 EST Last Modified: 2015-12-18 19:44 EST ====================================================================== Summary: FindOpenssl can't find self built openssl but prefers slproweb openssl Description: When having a pre-built package of openssl installed from slproweb.com and you try to find a self-built openssl package in a different location, the slproweb stuff is always preferred. Steps to Reproduce: 1) Install slproweb openssl development package (including import libraries and headers). 2a) Build openssl yourself or 2b) copy over the include directory and the lib directory from the slproweb location and delete the VC and the MinGW folder inside the lib dir. 3) run find_package(OpenSSL) -> you will not be able to find the new location, which contains both ssleay32.lib and libeay32.lib Additional Information: The problem occurs because ssleay32MD.lib/ssleay32MT.lib and libeay32MD.lib/libeay32MT.lib are searched before trying to find ssleay32.lib and libeay32.lib. Since the registry paths are by default in the HINTS section, these will be used first. Attached patch fixes this by providing an option OPENSSL_MSVC_NO_RT_MODE which disables searching for MD/MT libraries. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-12-18 19:44 Patrick SpendrinNew Issue 2015-12-18 19:44 Patrick SpendrinFile Added: 0001-Make-it-possible-to-ignore-slproweb-OpenSSL.patch ====================================================================== From ps_ml at gmx.de Fri Dec 18 19:49:13 2015 From: ps_ml at gmx.de (Patrick Spendrin) Date: Sat, 19 Dec 2015 01:49:13 +0100 Subject: [cmake-developers] Can't find correct openssl on Windows Message-ID: <5674A989.8000202@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have a small problem: when I try to search for my self-built openssl, cmake always prefers the slproweb.com packages instead of my own ones (even when setting OPENSSL_ROOT_DIR). This is due to the different naming of the libraries in the slproweb installation: There, you'll find ssleay32MD.lib vs. ssleay32.lib in my location. I already opened a bug report for that: https://public.kitware.com/Bug/view.php?id=15887 I attached a patch both here and at the bug report which fixes this behaviour for the cost of having an additional and ugly option for the FindOpenSSL.cmake file. I don't see a different solution, as the no-MD/MT version of the library is the backup solution (although the one I would prefer in this case). If you have any other idea, please let me know. regards, Patrick -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (MingW32) iQIcBAEBAgAGBQJWdKmJAAoJEPAKI6QtGt1xB60QAIyVhBdjiqT/yRKE2GsCTj2o xdOKlyMJ8BozJB5KP34QndzVCpKEsC+rs8UStKjk7N0P5Qly3URuRTKG375wDXw1 3d1unxDfDUplTj/vCKjzKFD9lZxmACkJ9/9MHy7jhjWfYIxFUbxDMQvMWnzsSgSZ daC0lxG65ggUBpYtA32TeM9GP2zB8ebAd6gSoDN+Iz3bJrl5cWvb1fom1nh0+2XV fjGQ23yeraJGpzMF96siPXuk9XFoJvQfShIn2cBILjWHqr+NohlPayY6qQkFz4C5 Ock9aMwAYhhbVmJzFWho2A1+qFYGJq0fLnS1Qb/+uJg7GTtI8bC/PQynnbkt+q93 jP7UwlKzqFHUhlhkO7gmTZv8np3bxLUNYTblZvCED1iF4kdlzCwbeNfIqf5y4zev ndInmEqvsODZwshcOqRFbX1nxq93/ZVUAaNy9ESlOBiL6xB2qHl+WOq4vNjZdh7w Pav2UqiEpmyC/x8aFfafrkDDEY4pMf6J/s0U21M8QMXQXw/QErFF8pLGXszLFrqz vJc+M3j45AZ9TLu86Uwekt6Z9WAtfXtfvQGaVH5bSicz7UBopjW5oX+U+3VO83Sa 0vwSmDNbOIo7YVmjtMc4d1xJwYWsbAQ1tXnfUgk66LGZStOHzjYWhUAFoAXZGOCV S4jiUpisEtRhtJSOkNoG =nozd -----END PGP SIGNATURE----- -------------- next part -------------- From 9fd1bfa174a8c8a5e63d875492ed01e7df34d1d7 Mon Sep 17 00:00:00 2001 From: Patrick Spendrin Date: Sat, 19 Dec 2015 01:16:15 +0100 Subject: [PATCH] Make it possible to ignore slproweb OpenSSL slproweb binary installations are found by default and their file naming convention is preferred over the ones openssl generates by default (without MD/MT). This change makes it possible to only find libraries without MD/MT by setting OPENSSL_MSVC_NO_RT_MODE=TRUE --- Modules/FindOpenSSL.cmake | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/Modules/FindOpenSSL.cmake b/Modules/FindOpenSSL.cmake index 8b4b988..c78896b 100644 --- a/Modules/FindOpenSSL.cmake +++ b/Modules/FindOpenSSL.cmake @@ -38,6 +38,7 @@ # Set ``OPENSSL_ROOT_DIR`` to the root directory of an OpenSSL installation. # Set ``OPENSSL_USE_STATIC_LIBS`` to ``TRUE`` to look for static libraries. # Set ``OPENSSL_MSVC_STATIC_RT`` set ``TRUE`` to choose the MT version of the lib. +# Set ``OPENSSL_MSVC_NO_RT_MODE`` set ``TRUE`` to use libraries without MD / MT in their name. #============================================================================= # Copyright 2006-2009 Kitware, Inc. @@ -108,7 +109,6 @@ find_path(OPENSSL_INCLUDE_DIR PATH_SUFFIXES include ) - if(WIN32 AND NOT CYGWIN) if(MSVC) # /MD and /MDd are the standard values - if someone wants to use @@ -127,10 +127,14 @@ if(WIN32 AND NOT CYGWIN) # ssleay32MD.lib is identical to ../ssleay32.lib # enable OPENSSL_USE_STATIC_LIBS to use the static libs located in lib/VC/static - if (OPENSSL_MSVC_STATIC_RT) - set(_OPENSSL_MSVC_RT_MODE "MT") + if (NOT OPENSSL_MSVC_NO_RT_MODE) + if (OPENSSL_MSVC_STATIC_RT) + set(_OPENSSL_MSVC_RT_MODE "MT") + else () + set(_OPENSSL_MSVC_RT_MODE "MD") + endif () else () - set(_OPENSSL_MSVC_RT_MODE "MD") + set(_OPENSSL_MSVC_RT_MODE "") endif () if(OPENSSL_USE_STATIC_LIBS) -- 2.6.3.windows.1 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-it-possible-to-ignore-slproweb-OpenSSL.patch.sig Type: application/octet-stream Size: 543 bytes Desc: not available URL: From mantis at public.kitware.com Sat Dec 19 09:44:47 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 19 Dec 2015 09:44:47 -0500 Subject: [cmake-developers] [CMake 0015888]: No FindGTK3.cmake by default Message-ID: <2ad504a843537694859b3976ea9d44aa@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15888 ====================================================================== Reported By: Ignat Loskutov Assigned To: ====================================================================== Project: CMake Issue ID: 15888 Category: Modules Reproducibility: always Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2015-12-19 09:44 EST Last Modified: 2015-12-19 09:44 EST ====================================================================== Summary: No FindGTK3.cmake by default Description: For some reason, there is no FindGTK3 module yet, while FindGTK2 and FindGTK (last probably only used by https://cmake.org/Bug/view.php?id=41#c1.5 retrogrades) exist. It makes many developers re-invent FindGTK3 again and again, while it could be provided with CMake by default instead. Additional Information: Examples of existing FindGTK3.cmake: https://github.com/eiskaltdcpp/eiskaltdcpp/blob/master/cmake/FindGTK3.cmake ? a clone of FindGTK2.cmake https://chromium.googlesource.com/external/Webkit/+/master/Source/cmake/FindGTK3.cmake ? PkgConfig-based solution ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-12-19 09:44 Ignat Loskutov New Issue ====================================================================== From ruslan_baratov at yahoo.com Sat Dec 19 12:27:42 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Sun, 20 Dec 2015 00:27:42 +0700 Subject: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle. In-Reply-To: <1450453565837.62019@tomtom.com> References: <1449759153039.51334@tomtom.com> <1813369686.65723125.1449847446080.JavaMail.zimbra@elemtech.com> <1449853301422.90915@tomtom.com> <2780526.IlfGfMxfeF@stryke> <910432174.66323078.1449861684460.JavaMail.zimbra@elemtech.com> <1449866813173.56940@tomtom.com> <566B712B.6060503@yahoo.com> <1449889708273.6810@tomtom.com> <566BB545.3090701@yahoo.com> <1450453565837.62019@tomtom.com> Message-ID: <5675938E.5050509@yahoo.com> On 18-Dec-15 22:46, Bartosz Kosiorek wrote: > > Thank you all for your tips/advice. > > > From our experience IDE generators (eg. Visual Studio, Xcode) is > much slower than Make or Ninja. I will attach benchmarks later. > > > Unfortunately I'm unable to build Universal libraries for x86 and arm > architectures by using Makefile. > This feature will work only for Xcode. For Makefile generator variable/property IOS_INSTALL_COMBINED is ignored. Xcode and Makefile differs in internals. Xcode can hold in build directory all variants of library like Release/Debug + Simulator/Device: Debug-iphoneos/libfoo.a # xcodebuild -sdk iphoneos -config Debug Debug-iphonesimulator/libfoo.a # xcodebuild -sdk iphonesimulator -config Debug Release-iphoneos/libfoo.a # xcodebuild -sdk iphoneos -config Release Release-iphonesimulator/libfoo.a # xcodebuild -sdk iphonesimulator -config Release Makefile holds only one variant so building both Simulator/Device in one project is tricky. You can build/install several libraries by Makefile and combine them with lipo using some external script. > See attached logs. > > > It seems that two different SDK's (iPhoneOS and iPhoneSimulator) needs > to be used in that case. > > Do you know how it could be fixed? > > Maybe I should add "CMAKE_OSX_SYSROOT "iphoneos" support for other > generators? > > What do you think about that idea? > > > Thanks in advance > > Bartosz? > > > PS > > I'm attaching the script which I'm using for testing purposes. > > To reproduce it just run command (from command line): > > cd builddir && cmake .. && cmake --build . > > > > > *From:*Ruslan Baratov [mailto:ruslan_baratov at yahoo.com] > *Sent:* Saturday, December 12, 2015 6:49 AM > *To:* Bartosz Kosiorek > *Cc:* Clinton Stimpson; Gregor Jasny; CMake Developers > *Subject:* Re: [cmake-developers] Create subdirectories in Resource > directory for Frameworks and Application bundle. > > On 12-Dec-15 10:08, Bartosz Kosiorek wrote: > > Thanks Ruslan. > > I would like to create instruction which is universal for all > generators. > > I think it's not possible. E.g. IOS_INSTALL_COMBINED will work only > for Xcode. > > > Currently we would like to support both Make/Ninja and Xcode generators, > > ... > > > because Make is much faster than Xcode generator, and we are using it > in our CI system. > > Do you mean generate step or build? I've used to compile quite big > projects like OpenCV with Xcode and according to the `top` it uses all > my cores with clang++ at 100% CPU time. > Can you show any benchmarks? Also note that Xcode can add some > additional stuff, like dSYM: > https://github.com/headupinclouds/gatherer/pull/69 > > > Make is also common for other architectures (Linux, QNX, Android etc.) > > Unfortunately > > set(CMAKE_OSX_SYSROOT "iphoneos") > > is not working for me. > > It displays error: > > /Users/warsaw/Perforce/cmake-dev/cmake-build/bin/cmake .. && > /Users/warsaw/Perforce/cmake-dev/cmake-build/bin/cmake --build . > > -- Configuring done > > -- Generating done > > -- Build files have been written to: > /Users/warsaw/Perforce/cmake_ios_framework_with_resource2/builddir > > [ 14%] Building C object > shared_empty/heymath/CMakeFiles/heymath.dir/add.c.o > > clang: warning: no such sysroot directory: 'iphoneos' > > ... > > Do you have some tip for that? > > Yes, this hint was for Xcode generator. > > > After removing "-isysroot ${CMAKE_OSX_SYSROOT}" everything works > perfectly. Thanks > > Unfortunately CMAKE_XCODE_ATTRIBUTE_IPHONEOS_DEPLOYMENT_TARGET is not > working with Make. > > Is it possible to introduce CMAKE_IOS_DEPLOYMENT_TARGET, as we already > have CMAKE_OSX_DEPLOYMENT_TARGET? > > Since OSX_ARCHITECTURES controls iOS architectures too I think request > should sounds like "Extend OSX_DEPLOYMENT_TARGET property for iOS > platform". > > > > I have attached my example script which I'm using. > > ?Could you please modify it to be better (and still support other > generators)? > > I don't know how to use iOS target with Makefile generator. > > Some notes about project you've sent: > * You need to add instructions to codesign your bundle > * Instead of hardcoding `set(CMAKE_OSX_SYSROOT > "/Applications/Xcode.app/.../iPhoneSimulator.sdk")` you can run > `xcode-select -print-path` to detect location of default Xcode version > * Should be `set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} > -mios-version-min=8.0")` instead of `set(CMAKE_CXX_FLAGS > "-mios-version-min=8.0")` otherwise some flags may be lost > > Ruslan > > Best Regards > > Bartosz > > ------------------------------------------------------------------------ > > *From:*Ruslan Baratov > > *Sent:* Saturday, December 12, 2015 1:58 AM > *To:* Bartosz Kosiorek > *Cc:* clinton at elemtech.com; Gregor Jasny; > CMake Developers > *Subject:* Re: [cmake-developers] Create subdirectories in Resource > directory for Frameworks and Application bundle. > > On 12-Dec-15 03:46, Bartosz Kosiorek wrote: > > Hi > > To enable iOS build, I'm using following settings in CMakeLists.txt: > > set(APPLE_PLATFORM "iphonesimulator") > > I think this one not needed. Can't find any place where it parsed. > > > set(CMAKE_OSX_SYSROOT > "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk") > > Can be set to: > > set(CMAKE_OSX_SYSROOT "iphoneos") > > in this case will support both simulator and device > > > set(CMAKE_C_FLAGS "-isysroot ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0") > > set(CMAKE_CXX_FLAGS "-isysroot ${CMAKE_OSX_SYSROOT} > -mios-version-min=7.0") > > You can set minimum version by > CMAKE_XCODE_ATTRIBUTE_IPHONEOS_DEPLOYMENT_TARGET variable. > In case of `CMAKE_OSX_SYSROOT` variable is set to `iphoneos` option > `-isysroot` is redundant. > > > Do you think it should be documented? > > Where is the good place to do so? > > Maybe somewhere here: > > https://cmake.org/cmake/help/v3.4/variable/CMAKE_OSX_SYSROOT.html > > What do you think? > > ? > > ------------------------------------------------------------------------ > > *From:*clinton at elemtech.com > *Sent:* Friday, December 11, 2015 8:21 PM > *To:* Bartosz Kosiorek > *Cc:* Bartosz Kosiorek; cmake-developers; Gregor Jasny > *Subject:* Re: [cmake-developers] Create subdirectories in Resource > directory for Frameworks and Application bundle. > > ----- On Dec 11, 2015, at 11:44 AM, Bartosz Kosiorek > wrote: > > Hi > > Because there is difference between OS X and iOS Bundles directory > structure (see: Apple specification > https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html), > > in trunk (In CMake 3.5) RESOURCE property create corresponding > directory structure. > > I have already fix that with: > https://public.kitware.com/Bug/view.php?id=15848 > > Ok. I hadn't been following all your work. > > Also, I didn't see a toggle in the CMake code you sent to choose an > iOS bundle instead of OS X bundles. How is that toggled? > > So RESOURCE gives you a level of abstraction: > > For OSX: > > it will create "Resource" directory > > For iOS it will create "flat" directory structure. > > In your example "Resource" directory will be created in both cases > (for OSX and iOS). > > Which is wrong: > For OSX: it should create "Resource" directory > For iOS it will create "flat" directory structure. > > I could provide patch to fix that issue, if you agree with that. > > What do you think about that? > > Do you think the same should be applied to "Headers"? > > I think the abstraction seems reasonable, as well as what you are > proposing. However, I'm not an Apple guru. > > I wonder if there are other Apple experts that can weigh in this if > better feedback is needed. > > Clint > > > Best Regards > > Bartosz > > 2015-12-11 19:06 GMT+01:00 Clinton Stimpson > >: > > > > On Friday, December 11, 2015 05:01:41 PM Bartosz Kosiorek wrote: > > Thanks Clint > > > > Unfortunately MACOSX_PACKAGE_LOCATION is not working correctly > with RESOURCE > > property. For every resource which is marked as RESOURCE, will > be placed in > > root "Resources" directory. > > > > The CMake code below create following directory structure for OS X: > > > > ?? mul.framework > > ??? Headers -> Versions/Current/Headers > > ??? Resources -> Versions/Current/Resources > > ??? Versions > > ? ??? A > > ? ? ??? Headers > > ? ? ? ??? mul.h > > ? ? ??? Modules > > ? ? ? ??? module.modulemap > > ? ? ??? Resources > > ? ? ? ??? Info.plist > > ? ? ? ??? mulres.txt > > ? ? ? ??? pl.txt > > ? ? ? ??? resourcefile.txt > > ? ? ??? lang > > ? ? ? ??? en.txt > > ? ? ??? mul > > ? ??? Current -> A > > ??? mul -> Versions/Current/mul > > > > > > As you can see eveything which is marked as "RESOURCE" will be > placed in > > Versions/A/ directory My expectation will be that lang/pl.txt and > > lang/en.txt should be in Resources/lang/ directory. Here is complete > > directory structure: > > > > ?? mul.framework > > ??? Headers -> Versions/Current/Headers > > ??? Resources -> Versions/Current/Resources > > ??? Versions > > ? ??? A > > ? ? ??? Headers > > ? ? ? ??? mul.h > > ? ? ??? Modules > > ? ? ? ??? module.modulemap > > ? ? ??? Resources > > ? ? ? ??? Info.plist > > ? ? ? ??? mulres.txt > > ? ? ? ??? lang > > ? ? ? ? ??? pl.txt > > ? ? ? ? ??? en.txt > > ? ? ? ??? resourcefile.txt > > ? ? ??? lang > > ? ? ? ??? en.txt > > ? ? ??? mul > > ? ??? Current -> A > > ??? mul -> Versions/Current/mul > > > > > > What do you think about that? > > > > Here is the source code: > > > > set_property(SOURCE module.modulemap > > PROPERTY MACOSX_PACKAGE_LOCATION "Modules") > > > > set_property( > > SOURCE lang/en.txt lang/pl.txt > > PROPERTY MACOSX_PACKAGE_LOCATION "lang") > > > > set(RESLIST > > mulres.txt > > lang/pl.txt > > resourcefile.txt > > ) > > > > add_library(mul SHARED > > mul.c > > mul.h > > module.modulemap > > lang/pl.txt > > lang/en.txt > > resourcefile.txt > > mulres.txt) > > > > # Create an iOS Framework bundle > > set_target_properties(mul PROPERTIES > > FRAMEWORK TRUE > > MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul > > MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 > > MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 > > XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" > > PUBLIC_HEADER mul.h > > RESOURCE "${RESLIST}" > > ) > > Here is a CMakeLists.txt that will give you the desired layout. > I also see that MACOSX_PACKAGE_LOCATION doesn't work with RESOURCE. > > > set_property(SOURCE module.modulemap > PROPERTY MACOSX_PACKAGE_LOCATION "Modules") > > set_property( > SOURCE lang/pl.txt lang/en.txt > PROPERTY MACOSX_PACKAGE_LOCATION "Resources/lang") > > set(RESLIST > mulres.txt > resourcefile.txt > ) > > add_library(mul SHARED > mul.c > mul.h > module.modulemap > lang/pl.txt > lang/en.txt > resourcefile.txt > mulres.txt) > > # Create an iOS Framework bundle > set_target_properties(mul PROPERTIES > FRAMEWORK TRUE > MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul > MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 > MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 > XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" > PUBLIC_HEADER mul.h > RESOURCE "${RESLIST}" > ) > > > Now I'm wondering what does the RESOURCE target property do that > MACOSX_PACKAGE_LOCATION doesn't already support? > > > Clint > -- > > 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Sat Dec 19 16:00:29 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 19 Dec 2015 16:00:29 -0500 Subject: [cmake-developers] [CMake 0015889]: IA64 compilers not found in Visual Studio 2010 (and probably others) Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15889 ====================================================================== Reported By: Vivien Assigned To: ====================================================================== Project: CMake Issue ID: 15889 Category: CMake Reproducibility: always Severity: major Priority: high Status: new ====================================================================== Date Submitted: 2015-12-19 16:00 EST Last Modified: 2015-12-19 16:00 EST ====================================================================== Summary: IA64 compilers not found in Visual Studio 2010 (and probably others) Description: In the CMakeDetermineCompilerId at line 186 there is : set(id_platform ia64) this leads to generate a bad CompilerIdC(XX).vcxproj with Debug|ia64 and Release|ia64 configurations, not recognized by devenv.exe. Indeed devenv.exe onyl recognize "Itanium". The question is why changing "Itanium" to "ia64" in the .cmake because without this line everything goes well and the IA compilers are found Steps to Reproduce: Try to configure any CMake project with Visual Studio 2010 IA64, and compilers won't be found. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-12-19 16:00 Vivien New Issue ====================================================================== From daniel at pfeifer-mail.de Sun Dec 20 15:07:38 2015 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Sun, 20 Dec 2015 21:07:38 +0100 Subject: [cmake-developers] Restriction on target types for GraphViz dependency graph generation In-Reply-To: References: Message-ID: On Wed, Dec 16, 2015 at 5:20 AM, Andrey Mishchenko wrote: > Hi, > > I noticed that the automatic dependency graph generation in CMake targeting > GraphViz only considers targets of certain types. In particular, it only > adds nodes for executables and shared, static, and module libraries. > > Is this deliberate? There are open issues about that: https://cmake.org/Bug/view.php?id=13809 https://cmake.org/Bug/view.php?id=15636 https://cmake.org/Bug/view.php?id=15638 > If I submit a patch extending this functionality to (optionally, via > configuration variables) work with more target types, would it be received > well? Absolutely. Thanks for working on this! -- Daniel From niels_ole at salscheider-online.de Sun Dec 20 17:07:58 2015 From: niels_ole at salscheider-online.de (Niels Ole Salscheider) Date: Sun, 20 Dec 2015 23:07:58 +0100 Subject: [cmake-developers] [PATCH] QtDialog: Allow to set CMAKE_SHARE_DIR Message-ID: <1450649278-20938-1-git-send-email-niels_ole@salscheider-online.de> This is needed for multiarch layouts where the prefix is /usr/${host} but where arch-independet files are installed to /usr/share. --- Source/CMakeInstallDestinations.cmake | 3 +++ Source/QtDialog/CMakeLists.txt | 6 +++--- bootstrap | 7 +++++++ 3 files changed, 13 insertions(+), 3 deletions(-) diff --git a/Source/CMakeInstallDestinations.cmake b/Source/CMakeInstallDestinations.cmake index 99c86ca..b0cbc85 100644 --- a/Source/CMakeInstallDestinations.cmake +++ b/Source/CMakeInstallDestinations.cmake @@ -13,6 +13,8 @@ else() set(CMAKE_MAN_DIR_DEFAULT "man") # OTHER endif() +set(CMAKE_SHARE_DIR_DEFAULT "share") + set(CMAKE_DATA_DIR_DESC "data") set(CMAKE_DOC_DIR_DESC "docs") set(CMAKE_MAN_DIR_DESC "man pages") @@ -21,6 +23,7 @@ foreach(v CMAKE_DATA_DIR CMAKE_DOC_DIR CMAKE_MAN_DIR + CMAKE_SHARE_DIR ) # Populate the cache with empty values so we know when the user sets them. set(${v} "" CACHE STRING "") diff --git a/Source/QtDialog/CMakeLists.txt b/Source/QtDialog/CMakeLists.txt index 9161ad3..9137695 100644 --- a/Source/QtDialog/CMakeLists.txt +++ b/Source/QtDialog/CMakeLists.txt @@ -193,7 +193,7 @@ if(UNIX AND NOT APPLE) foreach (size IN ITEMS 32 128) install( FILES "${CMAKE_CURRENT_SOURCE_DIR}/CMakeSetup${size}.png" - DESTINATION "share/icons/hicolor/${size}x${size}/apps" + DESTINATION "${CMAKE_SHARE_DIR}/icons/hicolor/${size}x${size}/apps" ${COMPONENT} RENAME "CMakeSetup.png") endforeach () @@ -201,10 +201,10 @@ if(UNIX AND NOT APPLE) # install a desktop file so CMake appears in the application start menu # with an icon install(FILES CMake.desktop - DESTINATION share/applications + DESTINATION "${CMAKE_SHARE_DIR}/applications" ${COMPONENT}) install(FILES cmakecache.xml - DESTINATION share/mime/packages + DESTINATION "${CMAKE_SHARE_DIR}/mime/packages" ${COMPONENT}) endif() diff --git a/bootstrap b/bootstrap index b2421a1..27f1efd 100755 --- a/bootstrap +++ b/bootstrap @@ -63,9 +63,11 @@ cmake_copyright="`grep '^Copyright .* Kitware' "${cmake_source_dir}/Copyright.tx cmake_data_dir_keyword="OTHER" cmake_doc_dir_keyword="OTHER" cmake_man_dir_keyword="OTHER" +cmake_share_dir_keyword="OTHER" cmake_data_dir="" cmake_doc_dir="" cmake_man_dir="" +cmake_share_dir="" cmake_init_file="" cmake_bootstrap_system_libs="" cmake_bootstrap_qt_gui="" @@ -214,6 +216,7 @@ fi cmake_data_dir_default="`cmake_install_dest_default DATA ${cmake_data_dir_keyword}`" cmake_doc_dir_default="`cmake_install_dest_default DOC ${cmake_doc_dir_keyword}`" cmake_man_dir_default="`cmake_install_dest_default MAN ${cmake_man_dir_keyword}`" +cmake_share_dir_default="`cmake_install_dest_default SHARE ${cmake_share_dir_keyword}`" CMAKE_KNOWN_C_COMPILERS="cc gcc xlc icc tcc" CMAKE_KNOWN_CXX_COMPILERS="aCC xlC CC g++ c++ icc como " @@ -428,6 +431,8 @@ Directory and file names: ['"${cmake_doc_dir_default}"'] --mandir=DIR install man pages files in PREFIX/DIR/manN ['"${cmake_man_dir_default}"'] + --sharedir=DIR install architecture-independent files in PREFIX/DIR + ['"${cmake_share_dir_default}"'] ' exit 10 } @@ -616,6 +621,7 @@ while test $# != 0; do --datadir=*) cmake_data_dir=`cmake_arg "$1"` ;; --docdir=*) cmake_doc_dir=`cmake_arg "$1"` ;; --mandir=*) cmake_man_dir=`cmake_arg "$1"` ;; + --sharedir=*) cmake_share_dir=`cmake_arg "$1"` ;; --init=*) cmake_init_file=`cmake_arg "$1"` ;; --system-libs) cmake_bootstrap_system_libs="${cmake_bootstrap_system_libs} -DCMAKE_USE_SYSTEM_LIBRARIES=1" ;; --no-system-libs) cmake_bootstrap_system_libs="${cmake_bootstrap_system_libs} -DCMAKE_USE_SYSTEM_LIBRARIES=0" ;; @@ -1368,6 +1374,7 @@ set (CMAKE_INSTALL_PREFIX "'"${cmake_prefix_dir}"'" CACHE PATH "Install path pre set (CMAKE_DOC_DIR "'"${cmake_doc_dir}"'" CACHE PATH "Install location for documentation (relative to prefix)." FORCE) set (CMAKE_MAN_DIR "'"${cmake_man_dir}"'" CACHE PATH "Install location for man pages (relative to prefix)." FORCE) set (CMAKE_DATA_DIR "'"${cmake_data_dir}"'" CACHE PATH "Install location for data (relative to prefix)." FORCE) +set (CMAKE_SHARE_DIR "'"${cmake_share_dir}"'" CACHE PATH "Install location for architecture-independent files (relative to prefix)." FORCE) ' > "${cmake_bootstrap_dir}/InitialCacheFlags.cmake" # Add configuration settings given as command-line options. -- 2.6.4 From Bartosz.Kosiorek at tomtom.com Mon Dec 21 05:19:19 2015 From: Bartosz.Kosiorek at tomtom.com (Bartosz Kosiorek) Date: Mon, 21 Dec 2015 10:19:19 +0000 Subject: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle. In-Reply-To: <5675938E.5050509@yahoo.com> References: <1449759153039.51334@tomtom.com> <1813369686.65723125.1449847446080.JavaMail.zimbra@elemtech.com> <1449853301422.90915@tomtom.com> <2780526.IlfGfMxfeF@stryke> <910432174.66323078.1449861684460.JavaMail.zimbra@elemtech.com> <1449866813173.56940@tomtom.com> <566B712B.6060503@yahoo.com> <1449889708273.6810@tomtom.com> <566BB545.3090701@yahoo.com> <1450453565837.62019@tomtom.com>,<5675938E.5050509@yahoo.com> Message-ID: <1450693159551.19800@tomtom.com> Thanks Ruslan for explanation. Currently we already building fat library for arm (armv7;armv7s;arm64) and x86 (i386;x86_64). That's why my original assumption was that it could be easily enabled for Simulator/device (armv7;armv7s;arm64;i386;x86_64). I could start working on that but if it will be too hacky, then I will leave that idea. BTW I made some benchmarks of Xcode vs Make comparison for our internal subproject (with "time" command). Here are results: Xcode generation: real 6m31.733s user 4m51.862s sys 0m20.268s Make generation: real 4m45.089s user 2m56.117s sys 0m17.481s Ninja generation: real 2m48.585s user 2m30.712s sys 0m6.313s Xcode generation + build time: real 64m3.238s user 353m36.825s sys 46m52.415s Make generation + build time: real 61m2.583s user 358m7.464s sys 47m21.512s So it seems in our case, for Generation performance step, we should use Ninja. Best Regards Bartosz ________________________________ From: Ruslan Baratov Sent: Saturday, December 19, 2015 6:27 PM To: Bartosz Kosiorek Cc: Clinton Stimpson; Gregor Jasny; CMake Developers Subject: Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle. On 18-Dec-15 22:46, Bartosz Kosiorek wrote: Thank you all for your tips/advice. From our experience IDE generators (eg. Visual Studio, Xcode) is much slower than Make or Ninja. I will attach benchmarks later. Unfortunately I'm unable to build Universal libraries for x86 and arm architectures by using Makefile. This feature will work only for Xcode. For Makefile generator variable/property IOS_INSTALL_COMBINED is ignored. Xcode and Makefile differs in internals. Xcode can hold in build directory all variants of library like Release/Debug + Simulator/Device: Debug-iphoneos/libfoo.a # xcodebuild -sdk iphoneos -config Debug Debug-iphonesimulator/libfoo.a # xcodebuild -sdk iphonesimulator -config Debug Release-iphoneos/libfoo.a # xcodebuild -sdk iphoneos -config Release Release-iphonesimulator/libfoo.a # xcodebuild -sdk iphonesimulator -config Release Makefile holds only one variant so building both Simulator/Device in one project is tricky. You can build/install several libraries by Makefile and combine them with lipo using some external script. See attached logs. It seems that two different SDK's (iPhoneOS and iPhoneSimulator) needs to be used in that case. Do you know how it could be fixed? Maybe I should add "CMAKE_OSX_SYSROOT "iphoneos" support for other generators? What do you think about that idea? Thanks in advance Bartosz? PS I'm attaching the script which I'm using for testing purposes. To reproduce it just run command (from command line): cd builddir && cmake .. && cmake --build . From: Ruslan Baratov [mailto:ruslan_baratov at yahoo.com] Sent: Saturday, December 12, 2015 6:49 AM To: Bartosz Kosiorek Cc: Clinton Stimpson; Gregor Jasny; CMake Developers Subject: Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle. On 12-Dec-15 10:08, Bartosz Kosiorek wrote: Thanks Ruslan. I would like to create instruction which is universal for all generators. I think it's not possible. E.g. IOS_INSTALL_COMBINED will work only for Xcode. Currently we would like to support both Make/Ninja and Xcode generators, ... because Make is much faster than Xcode generator, and we are using it in our CI system. Do you mean generate step or build? I've used to compile quite big projects like OpenCV with Xcode and according to the `top` it uses all my cores with clang++ at 100% CPU time. Can you show any benchmarks? Also note that Xcode can add some additional stuff, like dSYM: https://github.com/headupinclouds/gatherer/pull/69 Make is also common for other architectures (Linux, QNX, Android etc.) Unfortunately set(CMAKE_OSX_SYSROOT "iphoneos") is not working for me. It displays error: /Users/warsaw/Perforce/cmake-dev/cmake-build/bin/cmake .. && /Users/warsaw/Perforce/cmake-dev/cmake-build/bin/cmake --build . -- Configuring done -- Generating done -- Build files have been written to: /Users/warsaw/Perforce/cmake_ios_framework_with_resource2/builddir [ 14%] Building C object shared_empty/heymath/CMakeFiles/heymath.dir/add.c.o clang: warning: no such sysroot directory: 'iphoneos' ... Do you have some tip for that? Yes, this hint was for Xcode generator. After removing "-isysroot ${CMAKE_OSX_SYSROOT}" everything works perfectly. Thanks Unfortunately CMAKE_XCODE_ATTRIBUTE_IPHONEOS_DEPLOYMENT_TARGET is not working with Make. Is it possible to introduce CMAKE_IOS_DEPLOYMENT_TARGET, as we already have CMAKE_OSX_DEPLOYMENT_TARGET? Since OSX_ARCHITECTURES controls iOS architectures too I think request should sounds like "Extend OSX_DEPLOYMENT_TARGET property for iOS platform". I have attached my example script which I'm using. ?Could you please modify it to be better (and still support other generators)? I don't know how to use iOS target with Makefile generator. Some notes about project you've sent: * You need to add instructions to codesign your bundle * Instead of hardcoding `set(CMAKE_OSX_SYSROOT "/Applications/Xcode.app/.../iPhoneSimulator.sdk")` you can run `xcode-select -print-path` to detect location of default Xcode version * Should be `set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mios-version-min=8.0")` instead of `set(CMAKE_CXX_FLAGS "-mios-version-min=8.0")` otherwise some flags may be lost Ruslan Best Regards Bartosz ________________________________ From: Ruslan Baratov Sent: Saturday, December 12, 2015 1:58 AM To: Bartosz Kosiorek Cc: clinton at elemtech.com; Gregor Jasny; CMake Developers Subject: Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle. On 12-Dec-15 03:46, Bartosz Kosiorek wrote: Hi To enable iOS build, I'm using following settings in CMakeLists.txt: set(APPLE_PLATFORM "iphonesimulator") I think this one not needed. Can't find any place where it parsed. set(CMAKE_OSX_SYSROOT "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk") Can be set to: set(CMAKE_OSX_SYSROOT "iphoneos") in this case will support both simulator and device set(CMAKE_C_FLAGS "-isysroot ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0") set(CMAKE_CXX_FLAGS "-isysroot ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0") You can set minimum version by CMAKE_XCODE_ATTRIBUTE_IPHONEOS_DEPLOYMENT_TARGET variable. In case of `CMAKE_OSX_SYSROOT` variable is set to `iphoneos` option `-isysroot` is redundant. Do you think it should be documented? Where is the good place to do so? Maybe somewhere here: https://cmake.org/cmake/help/v3.4/variable/CMAKE_OSX_SYSROOT.html What do you think? ? ________________________________ From: clinton at elemtech.com Sent: Friday, December 11, 2015 8:21 PM To: Bartosz Kosiorek Cc: Bartosz Kosiorek; cmake-developers; Gregor Jasny Subject: Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle. ----- On Dec 11, 2015, at 11:44 AM, Bartosz Kosiorek wrote: Hi Because there is difference between OS X and iOS Bundles directory structure (see: Apple specification https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html), in trunk (In CMake 3.5) RESOURCE property create corresponding directory structure. I have already fix that with: https://public.kitware.com/Bug/view.php?id=15848 Ok. I hadn't been following all your work. Also, I didn't see a toggle in the CMake code you sent to choose an iOS bundle instead of OS X bundles. How is that toggled? So RESOURCE gives you a level of abstraction: For OSX: it will create "Resource" directory For iOS it will create "flat" directory structure. In your example "Resource" directory will be created in both cases (for OSX and iOS). Which is wrong: For OSX: it should create "Resource" directory For iOS it will create "flat" directory structure. I could provide patch to fix that issue, if you agree with that. What do you think about that? Do you think the same should be applied to "Headers"? I think the abstraction seems reasonable, as well as what you are proposing. However, I'm not an Apple guru. I wonder if there are other Apple experts that can weigh in this if better feedback is needed. Clint Best Regards Bartosz 2015-12-11 19:06 GMT+01:00 Clinton Stimpson <clinton at elemtech.com>: On Friday, December 11, 2015 05:01:41 PM Bartosz Kosiorek wrote: > Thanks Clint > > Unfortunately MACOSX_PACKAGE_LOCATION is not working correctly with RESOURCE > property. For every resource which is marked as RESOURCE, will be placed in > root "Resources" directory. > > The CMake code below create following directory structure for OS X: > > ?? mul.framework > ??? Headers -> Versions/Current/Headers > ??? Resources -> Versions/Current/Resources > ??? Versions > ? ??? A > ? ? ??? Headers > ? ? ? ??? mul.h > ? ? ??? Modules > ? ? ? ??? module.modulemap > ? ? ??? Resources > ? ? ? ??? Info.plist > ? ? ? ??? mulres.txt > ? ? ? ??? pl.txt > ? ? ? ??? resourcefile.txt > ? ? ??? lang > ? ? ? ??? en.txt > ? ? ??? mul > ? ??? Current -> A > ??? mul -> Versions/Current/mul > > > As you can see eveything which is marked as "RESOURCE" will be placed in > Versions/A/ directory My expectation will be that lang/pl.txt and > lang/en.txt should be in Resources/lang/ directory. Here is complete > directory structure: > > ?? mul.framework > ??? Headers -> Versions/Current/Headers > ??? Resources -> Versions/Current/Resources > ??? Versions > ? ??? A > ? ? ??? Headers > ? ? ? ??? mul.h > ? ? ??? Modules > ? ? ? ??? module.modulemap > ? ? ??? Resources > ? ? ? ??? Info.plist > ? ? ? ??? mulres.txt > ? ? ? ??? lang > ? ? ? ? ??? pl.txt > ? ? ? ? ??? en.txt > ? ? ? ??? resourcefile.txt > ? ? ??? lang > ? ? ? ??? en.txt > ? ? ??? mul > ? ??? Current -> A > ??? mul -> Versions/Current/mul > > > What do you think about that? > > Here is the source code: > > set_property(SOURCE module.modulemap > PROPERTY MACOSX_PACKAGE_LOCATION "Modules") > > set_property( > SOURCE lang/en.txt lang/pl.txt > PROPERTY MACOSX_PACKAGE_LOCATION "lang") > > set(RESLIST > mulres.txt > lang/pl.txt > resourcefile.txt > ) > > add_library(mul SHARED > mul.c > mul.h > module.modulemap > lang/pl.txt > lang/en.txt > resourcefile.txt > mulres.txt) > > # Create an iOS Framework bundle > set_target_properties(mul PROPERTIES > FRAMEWORK TRUE > MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul > MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 > MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 > XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" > PUBLIC_HEADER mul.h > RESOURCE "${RESLIST}" > ) Here is a CMakeLists.txt that will give you the desired layout. I also see that MACOSX_PACKAGE_LOCATION doesn't work with RESOURCE. set_property(SOURCE module.modulemap PROPERTY MACOSX_PACKAGE_LOCATION "Modules") set_property( SOURCE lang/pl.txt lang/en.txt PROPERTY MACOSX_PACKAGE_LOCATION "Resources/lang") set(RESLIST mulres.txt resourcefile.txt ) add_library(mul SHARED mul.c mul.h module.modulemap lang/pl.txt lang/en.txt resourcefile.txt mulres.txt) # Create an iOS Framework bundle set_target_properties(mul PROPERTIES FRAMEWORK TRUE MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" PUBLIC_HEADER mul.h RESOURCE "${RESLIST}" ) Now I'm wondering what does the RESOURCE target property do that MACOSX_PACKAGE_LOCATION doesn't already support? Clint -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Dec 21 09:12:40 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 21 Dec 2015 09:12:40 -0500 Subject: [cmake-developers] Can't find correct openssl on Windows In-Reply-To: <5674A989.8000202@gmx.de> References: <5674A989.8000202@gmx.de> Message-ID: <567808D8.8060409@kitware.com> On 12/18/2015 07:49 PM, Patrick Spendrin wrote: > I attached a patch both here and at the bug report which fixes this > behaviour for the cost of having an additional and ugly option for the > FindOpenSSL.cmake file. > I don't see a different solution, as the no-MD/MT version of the > library is the backup solution (although the one I would prefer in > this case). The OPENSSL_MSVC_NO_RT_MODE patch can be a fallback solution, but we may be able to avoid it. Take a look at the NAMES_PER_DIR option of the find_library command. Using that it should be possible to find the library of any name that appears first among the searched locations. FYI, one may avoid using OpenSSL altogether on Windows by using Schannel instead: https://msdn.microsoft.com/en-us/library/windows/desktop/aa380123.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa374782.aspx This is the approach CMake itself currently uses, in particular because it has the advantage of using the OS-maintained list of root CAs. -Brad From brad.king at kitware.com Mon Dec 21 09:17:22 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 21 Dec 2015 09:17:22 -0500 Subject: [cmake-developers] [PATCH] QtDialog: Allow to set CMAKE_SHARE_DIR In-Reply-To: <1450649278-20938-1-git-send-email-niels_ole@salscheider-online.de> References: <1450649278-20938-1-git-send-email-niels_ole@salscheider-online.de> Message-ID: <567809F2.7050602@kitware.com> On 12/20/2015 05:07 PM, Niels Ole Salscheider wrote: > This is needed for multiarch layouts where the prefix is /usr/${host} but > where arch-independet files are installed to /usr/share. Thanks. Some of the current install dir options default to `share/...` as seen in `Source/CMakeInstallDestinations.cmake`. Many of the corresponding installed files are also architecture-independent. The name `CMAKE_SHARE_DIR` sounds like it intends to replace all uses of `share/` and architecture- independent files when in fact it is only for gui system integration files. Can you propose a more-specific name and description for the option? Also, the `cmake_install_dest_default` function in the bootstrap script depends on the source code layout in `Source/CMakeInstallDestinations.cmake` and a "# OTHER" comment. Please revise and test that the bootstrap script extracts the matching default. Thanks, -Brad From brad.king at kitware.com Mon Dec 21 09:42:08 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 21 Dec 2015 09:42:08 -0500 Subject: [cmake-developers] Maintainer vacation until Jan 7 Message-ID: <56780FC0.7070309@kitware.com> Hi Folks, FYI, tomorrow I'm heading out for vacation and will likely not be responsive until at least Jan 7. -Brad From niels_ole at salscheider-online.de Mon Dec 21 10:02:11 2015 From: niels_ole at salscheider-online.de (Niels Ole Salscheider) Date: Mon, 21 Dec 2015 16:02:11 +0100 Subject: [cmake-developers] [PATCH v2] QtDialog: Allow to set CMAKE_XDGDATA_DIR In-Reply-To: <567809F2.7050602@kitware.com> References: <567809F2.7050602@kitware.com> Message-ID: <1450710131-10928-1-git-send-email-niels_ole@salscheider-online.de> This is needed for multiarch layouts where the prefix is /usr/${host} but where arch-independet files (like the XDG specific ones) are installed to /usr/share. --- Source/CMakeInstallDestinations.cmake | 5 +++++ Source/QtDialog/CMakeLists.txt | 6 +++--- bootstrap | 7 +++++++ 3 files changed, 15 insertions(+), 3 deletions(-) diff --git a/Source/CMakeInstallDestinations.cmake b/Source/CMakeInstallDestinations.cmake index 99c86ca..2f9d95a 100644 --- a/Source/CMakeInstallDestinations.cmake +++ b/Source/CMakeInstallDestinations.cmake @@ -3,24 +3,29 @@ if(BEOS) set(CMAKE_DATA_DIR_DEFAULT "share/cmake-${CMake_VERSION_MAJOR}.${CMake_VERSION_MINOR}") # HAIKU set(CMAKE_MAN_DIR_DEFAULT "documentation/man") # HAIKU set(CMAKE_DOC_DIR_DEFAULT "documentation/doc/cmake-${CMake_VERSION_MAJOR}.${CMake_VERSION_MINOR}") # HAIKU + set(CMAKE_XDGDATA_DIR_DEFAULT "share") # HAIKU elseif(CYGWIN) set(CMAKE_DATA_DIR_DEFAULT "share/cmake-${CMake_VERSION}") # CYGWIN set(CMAKE_DOC_DIR_DEFAULT "share/doc/cmake-${CMake_VERSION}") # CYGWIN set(CMAKE_MAN_DIR_DEFAULT "share/man") # CYGWIN + set(CMAKE_XDGDATA_DIR_DEFAULT "share") # CYGWIN else() set(CMAKE_DATA_DIR_DEFAULT "share/cmake-${CMake_VERSION_MAJOR}.${CMake_VERSION_MINOR}") # OTHER set(CMAKE_DOC_DIR_DEFAULT "doc/cmake-${CMake_VERSION_MAJOR}.${CMake_VERSION_MINOR}") # OTHER set(CMAKE_MAN_DIR_DEFAULT "man") # OTHER + set(CMAKE_XDGDATA_DIR_DEFAULT "share") # OTHER endif() set(CMAKE_DATA_DIR_DESC "data") set(CMAKE_DOC_DIR_DESC "docs") set(CMAKE_MAN_DIR_DESC "man pages") +set(CMAKE_XDGDATA_DIR_DESC "XDG specific files") foreach(v CMAKE_DATA_DIR CMAKE_DOC_DIR CMAKE_MAN_DIR + CMAKE_XDGDATA_DIR ) # Populate the cache with empty values so we know when the user sets them. set(${v} "" CACHE STRING "") diff --git a/Source/QtDialog/CMakeLists.txt b/Source/QtDialog/CMakeLists.txt index 9161ad3..f17de5d 100644 --- a/Source/QtDialog/CMakeLists.txt +++ b/Source/QtDialog/CMakeLists.txt @@ -193,7 +193,7 @@ if(UNIX AND NOT APPLE) foreach (size IN ITEMS 32 128) install( FILES "${CMAKE_CURRENT_SOURCE_DIR}/CMakeSetup${size}.png" - DESTINATION "share/icons/hicolor/${size}x${size}/apps" + DESTINATION "${CMAKE_XDGDATA_DIR}/icons/hicolor/${size}x${size}/apps" ${COMPONENT} RENAME "CMakeSetup.png") endforeach () @@ -201,10 +201,10 @@ if(UNIX AND NOT APPLE) # install a desktop file so CMake appears in the application start menu # with an icon install(FILES CMake.desktop - DESTINATION share/applications + DESTINATION "${CMAKE_XDGDATA_DIR}/applications" ${COMPONENT}) install(FILES cmakecache.xml - DESTINATION share/mime/packages + DESTINATION "${CMAKE_XDGDATA_DIR}/mime/packages" ${COMPONENT}) endif() diff --git a/bootstrap b/bootstrap index b2421a1..97e85bf 100755 --- a/bootstrap +++ b/bootstrap @@ -63,9 +63,11 @@ cmake_copyright="`grep '^Copyright .* Kitware' "${cmake_source_dir}/Copyright.tx cmake_data_dir_keyword="OTHER" cmake_doc_dir_keyword="OTHER" cmake_man_dir_keyword="OTHER" +cmake_xdgdata_dir_keyword="OTHER" cmake_data_dir="" cmake_doc_dir="" cmake_man_dir="" +cmake_xdgdata_dir="" cmake_init_file="" cmake_bootstrap_system_libs="" cmake_bootstrap_qt_gui="" @@ -214,6 +216,7 @@ fi cmake_data_dir_default="`cmake_install_dest_default DATA ${cmake_data_dir_keyword}`" cmake_doc_dir_default="`cmake_install_dest_default DOC ${cmake_doc_dir_keyword}`" cmake_man_dir_default="`cmake_install_dest_default MAN ${cmake_man_dir_keyword}`" +cmake_xdgdata_dir_default="`cmake_install_dest_default XDGDATA ${cmake_xdgdata_dir_keyword}`" CMAKE_KNOWN_C_COMPILERS="cc gcc xlc icc tcc" CMAKE_KNOWN_CXX_COMPILERS="aCC xlC CC g++ c++ icc como " @@ -428,6 +431,8 @@ Directory and file names: ['"${cmake_doc_dir_default}"'] --mandir=DIR install man pages files in PREFIX/DIR/manN ['"${cmake_man_dir_default}"'] + --xdgdatadir=DIR install XDG specific files in PREFIX/DIR + ['"${cmake_xdgdata_dir_default}"'] ' exit 10 } @@ -616,6 +621,7 @@ while test $# != 0; do --datadir=*) cmake_data_dir=`cmake_arg "$1"` ;; --docdir=*) cmake_doc_dir=`cmake_arg "$1"` ;; --mandir=*) cmake_man_dir=`cmake_arg "$1"` ;; + --xdgdatadir=*) cmake_xdgdata_dir=`cmake_arg "$1"` ;; --init=*) cmake_init_file=`cmake_arg "$1"` ;; --system-libs) cmake_bootstrap_system_libs="${cmake_bootstrap_system_libs} -DCMAKE_USE_SYSTEM_LIBRARIES=1" ;; --no-system-libs) cmake_bootstrap_system_libs="${cmake_bootstrap_system_libs} -DCMAKE_USE_SYSTEM_LIBRARIES=0" ;; @@ -1368,6 +1374,7 @@ set (CMAKE_INSTALL_PREFIX "'"${cmake_prefix_dir}"'" CACHE PATH "Install path pre set (CMAKE_DOC_DIR "'"${cmake_doc_dir}"'" CACHE PATH "Install location for documentation (relative to prefix)." FORCE) set (CMAKE_MAN_DIR "'"${cmake_man_dir}"'" CACHE PATH "Install location for man pages (relative to prefix)." FORCE) set (CMAKE_DATA_DIR "'"${cmake_data_dir}"'" CACHE PATH "Install location for data (relative to prefix)." FORCE) +set (CMAKE_XDGDATA_DIR "'"${cmake_xdgdata_dir}"'" CACHE PATH "Install location for XDG specific files (relative to prefix)." FORCE) ' > "${cmake_bootstrap_dir}/InitialCacheFlags.cmake" # Add configuration settings given as command-line options. -- 2.6.4 From steveire at gmail.com Mon Dec 21 10:07:46 2015 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 21 Dec 2015 16:07:46 +0100 Subject: [cmake-developers] CMakeFindDependencyMacro limitations References: <566DB6CA.1060801@codelibre.net> Message-ID: Roger Leigh wrote: > I've run into a few limitations in find_dependency. I'm not sure if > these are by design or could be fixed, so this is really a request for > further explanation or design rationale. > > The first issue is this: > > if (NOT ${dep}_FOUND) > > This seems to be making the assumption that the found variable matches > the dependency name, but the case used varies between modules and the > name is case sensitive, from my reading of cmake-language. Is this > correct? It is intentional, yes. See http://public.kitware.com/Bug/view.php?id=15412 The config-packages generated by cmake are canonical, so modules should set the ExactCase_FOUND to be a 'correct module'. > Even if so, should this optimisation be put here rather than > in find_package itself? I don't know the answer to this. > If case sensitivity/naming is an issue, could > the _FOUND variable be passed in as an argument, leaving the existing > behaviour as the default if unspecified? I don't think that's a good idea. > The reason for stripping EXACT isn't clear. If my package has a strict > requirement on another package, whether the caller has an exact > requirement for the version of my package has no bearing on the > requirements I have for my dependencies as far as I understand. What's > the reason for the existing behaviour? I don't know what you are referring to with 'stripping EXACT'. Perhaps you are looking at CMake < 3.0. See commit v3.0.0-rc2~10^2 (find_dependency: Don't propagate EXACT argument., 2014-03-06). > Support for find_package arguments is limited to the dependency name and > optionally the version. ... and optionally EXACT. > I can understand why REQUIRED and related > arguments are omitted--that is why find_dependency exists--but I'd quite > like to be able to specify COMPONENTS where needed e.g. with FindBoost, > and this is not currently possible. I don't remember whether this was discussed when designing find_dependency. Perhaps COMPONENTS could be added to the macro now. > I was wondering if we could perhaps make find_dependency handle and pass > through /all/ find_package arguments, minus REQUIRED/QUIET, so that > find_dependency can expose the additional functionality offered by > find_package. Some may not be useful, in which case they could be > omitted, but some like COMPONENTS may be required for the find_package > call to be useful. It might be possible, but might not be a good idea. What else do you want to pass in? Thanks, Steve. From brad.king at kitware.com Mon Dec 21 10:29:46 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 21 Dec 2015 10:29:46 -0500 Subject: [cmake-developers] [PATCH v2] QtDialog: Allow to set CMAKE_XDGDATA_DIR In-Reply-To: <1450710131-10928-1-git-send-email-niels_ole@salscheider-online.de> References: <567809F2.7050602@kitware.com> <1450710131-10928-1-git-send-email-niels_ole@salscheider-online.de> Message-ID: <56781AEA.8050108@kitware.com> On 12/21/2015 10:02 AM, Niels Ole Salscheider wrote: > This is needed for multiarch layouts where the prefix is /usr/${host} but > where arch-independet files (like the XDG specific ones) are installed to > /usr/share. Great, thanks. Applied: QtDialog: Add option to control XDG file install destination https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=76566621 -Brad From mantis at public.kitware.com Mon Dec 21 10:43:24 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 21 Dec 2015 10:43:24 -0500 Subject: [cmake-developers] [CMake 0015890]: file(STRINGS ..) doesn't work on single character files. Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15890 ====================================================================== Reported By: Fredrik Bj?rkenfors Assigned To: ====================================================================== Project: CMake Issue ID: 15890 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-12-21 10:43 EST Last Modified: 2015-12-21 10:43 EST ====================================================================== Summary: file(STRINGS ..) doesn't work on single character files. Description: If the file passed to file(STRINGS VAR) contains a single character file VAR will be empty. Steps to Reproduce: Run CMake on the attached project. Workaround: Adding any character to the input file, including an EOL character. Additional Information: If the file has less than 2 characters ReadBOM(std::istream& in) will set the failbit and the attempt to rewind the file will fail. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-12-21 10:43 Fredrik Bj?rkenforsNew Issue 2015-12-21 10:43 Fredrik Bj?rkenforsFile Added: CMake_bug.zip ====================================================================== From ruslan_baratov at yahoo.com Mon Dec 21 13:59:21 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Tue, 22 Dec 2015 01:59:21 +0700 Subject: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle. In-Reply-To: <1450693159551.19800@tomtom.com> References: <1449759153039.51334@tomtom.com> <1813369686.65723125.1449847446080.JavaMail.zimbra@elemtech.com> <1449853301422.90915@tomtom.com> <2780526.IlfGfMxfeF@stryke> <910432174.66323078.1449861684460.JavaMail.zimbra@elemtech.com> <1449866813173.56940@tomtom.com> <566B712B.6060503@yahoo.com> <1449889708273.6810@tomtom.com> <566BB545.3090701@yahoo.com> <1450453565837.62019@tomtom.com> <5675938E.5050509@yahoo.com> <1450693159551.19800@tomtom.com> Message-ID: <56784C09.7090706@yahoo.com> On 21-Dec-15 17:19, Bartosz Kosiorek wrote: > > Thanks Ruslan for explanation. > > > Currently we already building fat library for arm (armv7;armv7s;arm64) > and x86 (i386;x86_64). > > > That's why my original assumption was that it could be easily enabled > for Simulator/device (armv7;armv7s;arm64;i386;x86_64). > > I could start working on that but if it will be too hacky, then I will > leave that idea. > > > > BTW I made some benchmarks of Xcode vs Make comparison for our > internal subproject (with "time" command). Here are results: > > > Xcode generation: > > real6m31.733s > > user4m51.862s > > sys0m20.268s > > > Make generation: > > real4m45.089s > > user2m56.117s > > sys0m17.481s > > > Ninja generation: > > real2m48.585s > > user2m30.712s > > sys0m6.313s > > > > Xcode generation + build time: > > real64m3.238s > > user353m36.825s > > sys46m52.415s > > > Make generation + build time: > > real61m2.583s > > user358m7.464s > > sys47m21.512s > > > So it seems in our case, for Generation performance step, we should > use Ninja. > Ok, thanks for sharing it. This proves what I was thinking - there is no difference in build time, but generate time is better for Makefile. Probably you can profile CMake and find some bottlenecks. > > Best Regards > > Bartosz > > > ------------------------------------------------------------------------ > *From:* Ruslan Baratov > *Sent:* Saturday, December 19, 2015 6:27 PM > *To:* Bartosz Kosiorek > *Cc:* Clinton Stimpson; Gregor Jasny; CMake Developers > *Subject:* Re: [cmake-developers] Create subdirectories in Resource > directory for Frameworks and Application bundle. > On 18-Dec-15 22:46, Bartosz Kosiorek wrote: >> >> Thank you all for your tips/advice. >> >> >> From our experience IDE generators (eg. Visual Studio, Xcode) is >> much slower than Make or Ninja. I will attach benchmarks later. >> >> >> Unfortunately I'm unable to build Universal libraries for x86 and arm >> architectures by using Makefile. >> > This feature will work only for Xcode. For Makefile generator > variable/property IOS_INSTALL_COMBINED is ignored. Xcode and Makefile > differs in internals. Xcode can hold in build directory all variants > of library like Release/Debug + Simulator/Device: > > Debug-iphoneos/libfoo.a # xcodebuild -sdk iphoneos -config Debug > Debug-iphonesimulator/libfoo.a # xcodebuild -sdk iphonesimulator > -config Debug > Release-iphoneos/libfoo.a # xcodebuild -sdk iphoneos -config Release > Release-iphonesimulator/libfoo.a # xcodebuild -sdk iphonesimulator > -config Release > > Makefile holds only one variant so building both Simulator/Device in > one project is tricky. You can build/install several libraries by > Makefile and combine them with lipo using some external script. > >> See attached logs. >> >> >> It seems that two different SDK's (iPhoneOS and >> iPhoneSimulator) needs to be used in that case. >> >> Do you know how it could be fixed? >> >> Maybe I should add "CMAKE_OSX_SYSROOT "iphoneos" support for other >> generators? >> >> What do you think about that idea? >> >> >> Thanks in advance >> >> Bartosz? >> >> >> PS >> >> I'm attaching the script which I'm using for testing purposes. >> >> To reproduce it just run command (from command line): >> >> cd builddir && cmake .. && cmake --build . >> >> >> >> >> *From:*Ruslan Baratov [mailto:ruslan_baratov at yahoo.com] >> *Sent:* Saturday, December 12, 2015 6:49 AM >> *To:* Bartosz Kosiorek >> *Cc:* Clinton Stimpson; Gregor Jasny; CMake Developers >> *Subject:* Re: [cmake-developers] Create subdirectories in Resource >> directory for Frameworks and Application bundle. >> >> On 12-Dec-15 10:08, Bartosz Kosiorek wrote: >> >> Thanks Ruslan. >> >> I would like to create instruction which is universal for all >> generators. >> >> I think it's not possible. E.g. IOS_INSTALL_COMBINED will work only >> for Xcode. >> >> >> Currently we would like to support both Make/Ninja and Xcode generators, >> >> ... >> >> >> because Make is much faster than Xcode generator, and we are using it >> in our CI system. >> >> Do you mean generate step or build? I've used to compile quite big >> projects like OpenCV with Xcode and according to the `top` it uses >> all my cores with clang++ at 100% CPU time. >> Can you show any benchmarks? Also note that Xcode can add some >> additional stuff, like dSYM: >> https://github.com/headupinclouds/gatherer/pull/69 >> >> >> Make is also common for other architectures (Linux, QNX, Android etc.) >> >> Unfortunately >> >> set(CMAKE_OSX_SYSROOT "iphoneos") >> >> is not working for me. >> >> It displays error: >> >> /Users/warsaw/Perforce/cmake-dev/cmake-build/bin/cmake .. && >> /Users/warsaw/Perforce/cmake-dev/cmake-build/bin/cmake --build . >> >> -- Configuring done >> >> -- Generating done >> >> -- Build files have been written to: >> /Users/warsaw/Perforce/cmake_ios_framework_with_resource2/builddir >> >> [ 14%] Building C object >> shared_empty/heymath/CMakeFiles/heymath.dir/add.c.o >> >> clang: warning: no such sysroot directory: 'iphoneos' >> >> ... >> >> Do you have some tip for that? >> >> Yes, this hint was for Xcode generator. >> >> >> After removing "-isysroot ${CMAKE_OSX_SYSROOT}" everything works >> perfectly. Thanks >> >> Unfortunately CMAKE_XCODE_ATTRIBUTE_IPHONEOS_DEPLOYMENT_TARGET is not >> working with Make. >> >> Is it possible to introduce CMAKE_IOS_DEPLOYMENT_TARGET, as we >> already have CMAKE_OSX_DEPLOYMENT_TARGET? >> >> Since OSX_ARCHITECTURES controls iOS architectures too I think >> request should sounds like "Extend OSX_DEPLOYMENT_TARGET property for >> iOS platform". >> >> >> >> I have attached my example script which I'm using. >> >> ? Could you please modify it to be better (and still support other >> generators)? >> >> I don't know how to use iOS target with Makefile generator. >> >> Some notes about project you've sent: >> * You need to add instructions to codesign your bundle >> * Instead of hardcoding `set(CMAKE_OSX_SYSROOT >> "/Applications/Xcode.app/.../iPhoneSimulator.sdk")` you can run >> `xcode-select -print-path` to detect location of default Xcode version >> * Should be `set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} >> -mios-version-min=8.0")` instead of `set(CMAKE_CXX_FLAGS >> "-mios-version-min=8.0")` otherwise some flags may be lost >> >> Ruslan >> >> Best Regards >> >> Bartosz >> >> ------------------------------------------------------------------------ >> >> *From:*Ruslan Baratov >> >> *Sent:* Saturday, December 12, 2015 1:58 AM >> *To:* Bartosz Kosiorek >> *Cc:* clinton at elemtech.com; Gregor >> Jasny; CMake Developers >> *Subject:* Re: [cmake-developers] Create subdirectories in Resource >> directory for Frameworks and Application bundle. >> >> On 12-Dec-15 03:46, Bartosz Kosiorek wrote: >> >> Hi >> >> To enable iOS build, I'm using following settings in CMakeLists.txt: >> >> set(APPLE_PLATFORM "iphonesimulator") >> >> I think this one not needed. Can't find any place where it parsed. >> >> >> set(CMAKE_OSX_SYSROOT >> "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk") >> >> Can be set to: >> >> set(CMAKE_OSX_SYSROOT "iphoneos") >> >> in this case will support both simulator and device >> >> >> set(CMAKE_C_FLAGS "-isysroot ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0") >> >> set(CMAKE_CXX_FLAGS "-isysroot ${CMAKE_OSX_SYSROOT} >> -mios-version-min=7.0") >> >> You can set minimum version by >> CMAKE_XCODE_ATTRIBUTE_IPHONEOS_DEPLOYMENT_TARGET variable. >> In case of `CMAKE_OSX_SYSROOT` variable is set to `iphoneos` option >> `-isysroot` is redundant. >> >> >> Do you think it should be documented? >> >> Where is the good place to do so? >> >> Maybe somewhere here: >> >> https://cmake.org/cmake/help/v3.4/variable/CMAKE_OSX_SYSROOT.html >> >> What do you think? >> >> ? >> >> ------------------------------------------------------------------------ >> >> *From:*clinton at elemtech.com >> *Sent:* Friday, December 11, 2015 8:21 PM >> *To:* Bartosz Kosiorek >> *Cc:* Bartosz Kosiorek; cmake-developers; Gregor Jasny >> *Subject:* Re: [cmake-developers] Create subdirectories in Resource >> directory for Frameworks and Application bundle. >> >> ----- On Dec 11, 2015, at 11:44 AM, Bartosz Kosiorek >> wrote: >> >> Hi >> >> Because there is difference between OS X and iOS Bundles >> directory structure (see: Apple specification >> https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html), >> >> in trunk (In CMake 3.5) RESOURCE property create corresponding >> directory structure. >> >> I have already fix that with: >> https://public.kitware.com/Bug/view.php?id=15848 >> >> Ok. I hadn't been following all your work. >> >> Also, I didn't see a toggle in the CMake code you sent to choose an >> iOS bundle instead of OS X bundles. How is that toggled? >> >> So RESOURCE gives you a level of abstraction: >> >> For OSX: >> >> it will create "Resource" directory >> >> For iOS it will create "flat" directory structure. >> >> In your example "Resource" directory will be created in both >> cases (for OSX and iOS). >> >> Which is wrong: >> For OSX: it should create "Resource" directory >> For iOS it will create "flat" directory structure. >> >> I could provide patch to fix that issue, if you agree with that. >> >> What do you think about that? >> >> Do you think the same should be applied to "Headers"? >> >> I think the abstraction seems reasonable, as well as what you are >> proposing. However, I'm not an Apple guru. >> >> I wonder if there are other Apple experts that can weigh in this if >> better feedback is needed. >> >> Clint >> >> >> Best Regards >> >> Bartosz >> >> 2015-12-11 19:06 GMT+01:00 Clinton Stimpson >> <clinton at elemtech.com>: >> >> >> >> On Friday, December 11, 2015 05:01:41 PM Bartosz Kosiorek wrote: >> > Thanks Clint >> > >> > Unfortunately MACOSX_PACKAGE_LOCATION is not working correctly >> with RESOURCE >> > property. For every resource which is marked as RESOURCE, will >> be placed in >> > root "Resources" directory. >> > >> > The CMake code below create following directory structure for OS X: >> > >> > ?? mul.framework >> > ??? Headers -> Versions/Current/Headers >> > ??? Resources -> Versions/Current/Resources >> > ??? Versions >> > ? ??? A >> > ? ? ??? Headers >> > ? ? ? ??? mul.h >> > ? ? ??? Modules >> > ? ? ? ??? module.modulemap >> > ? ? ??? Resources >> > ? ? ? ??? Info.plist >> > ? ? ? ??? mulres.txt >> > ? ? ? ??? pl.txt >> > ? ? ? ??? resourcefile.txt >> > ? ? ??? lang >> > ? ? ? ??? en.txt >> > ? ? ??? mul >> > ? ??? Current -> A >> > ??? mul -> Versions/Current/mul >> > >> > >> > As you can see eveything which is marked as "RESOURCE" will be >> placed in >> > Versions/A/ directory My expectation will be that lang/pl.txt and >> > lang/en.txt should be in Resources/lang/ directory. Here is >> complete >> > directory structure: >> > >> > ?? mul.framework >> > ??? Headers -> Versions/Current/Headers >> > ??? Resources -> Versions/Current/Resources >> > ??? Versions >> > ? ??? A >> > ? ? ??? Headers >> > ? ? ? ??? mul.h >> > ? ? ??? Modules >> > ? ? ? ??? module.modulemap >> > ? ? ??? Resources >> > ? ? ? ??? Info.plist >> > ? ? ? ??? mulres.txt >> > ? ? ? ??? lang >> > ? ? ? ? ??? pl.txt >> > ? ? ? ? ??? en.txt >> > ? ? ? ??? resourcefile.txt >> > ? ? ??? lang >> > ? ? ? ??? en.txt >> > ? ? ??? mul >> > ? ??? Current -> A >> > ??? mul -> Versions/Current/mul >> > >> > >> > What do you think about that? >> > >> > Here is the source code: >> > >> > set_property(SOURCE module.modulemap >> > PROPERTY MACOSX_PACKAGE_LOCATION "Modules") >> > >> > set_property( >> > SOURCE lang/en.txt lang/pl.txt >> > PROPERTY MACOSX_PACKAGE_LOCATION "lang") >> > >> > set(RESLIST >> > mulres.txt >> > lang/pl.txt >> > resourcefile.txt >> > ) >> > >> > add_library(mul SHARED >> > mul.c >> > mul.h >> > module.modulemap >> > lang/pl.txt >> > lang/en.txt >> > resourcefile.txt >> > mulres.txt) >> > >> > # Create an iOS Framework bundle >> > set_target_properties(mul PROPERTIES >> > FRAMEWORK TRUE >> > MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul >> > MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 >> > MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 >> > XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" >> > PUBLIC_HEADER mul.h >> > RESOURCE "${RESLIST}" >> > ) >> >> Here is a CMakeLists.txt that will give you the desired layout. >> I also see that MACOSX_PACKAGE_LOCATION doesn't work with RESOURCE. >> >> >> set_property(SOURCE module.modulemap >> PROPERTY MACOSX_PACKAGE_LOCATION "Modules") >> >> set_property( >> SOURCE lang/pl.txt lang/en.txt >> PROPERTY MACOSX_PACKAGE_LOCATION "Resources/lang") >> >> set(RESLIST >> mulres.txt >> resourcefile.txt >> ) >> >> add_library(mul SHARED >> mul.c >> mul.h >> module.modulemap >> lang/pl.txt >> lang/en.txt >> resourcefile.txt >> mulres.txt) >> >> # Create an iOS Framework bundle >> set_target_properties(mul PROPERTIES >> FRAMEWORK TRUE >> MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul >> MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42 >> MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10 >> XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" >> PUBLIC_HEADER mul.h >> RESOURCE "${RESLIST}" >> ) >> >> >> Now I'm wondering what does the RESOURCE target property do that >> MACOSX_PACKAGE_LOCATION doesn't already support? >> >> >> Clint >> -- >> >> 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 >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Mon Dec 21 15:21:33 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 21 Dec 2015 15:21:33 -0500 Subject: [cmake-developers] [CMake 0015891]: CMake extracts non-standard filenames incorrectly from tarballs Message-ID: <457d049ecd8e251a5ade2bbb507334c6@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15891 ====================================================================== Reported By: Ben Boeckel Assigned To: ====================================================================== Project: CMake Issue ID: 15891 Category: CMake Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-12-21 15:21 EST Last Modified: 2015-12-21 15:21 EST ====================================================================== Summary: CMake extracts non-standard filenames incorrectly from tarballs Description: Attached is a tarball which contains a file "Appendix A \xc2\xa0 An Introduction to Preprocessor Metaprogramming.html" (the hex is a UTF-8 non-breaking-space). "cmake -E tar xzf" will extract the file improperly, mangling it. CMake can then not delete the mangled file. Using msys2's (from git-bash) to extract the tarball works as expected (the filename looks fine and cmake can delete it). ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-12-21 15:21 Ben Boeckel New Issue 2015-12-21 15:21 Ben Boeckel File Added: bad-filename.tar.gz ====================================================================== From mantis at public.kitware.com Tue Dec 22 05:51:18 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 22 Dec 2015 11:51:18 +0100 Subject: [cmake-developers] [CMake 0015892]: cmSystemTools::GetShortPath works not correct Message-ID: <83f85e2fc11cce23d1a2847f0147a2d5@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15892 ====================================================================== Reported By: Jan van Dorsten Assigned To: ====================================================================== Project: CMake Issue ID: 15892 Category: CMake Reproducibility: always Severity: major Priority: high Status: new ====================================================================== Date Submitted: 2015-12-22 11:51 CET Last Modified: 2015-12-22 11:51 CET ====================================================================== Summary: cmSystemTools::GetShortPath works not correct Description: The method "GetShortPath" does not work as expected. The error codes from the MSDN for the function "GetShortPathName" are not interpreted correctly. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-12-22 11:51 Jan van DorstenNew Issue 2015-12-22 11:51 Jan van DorstenFile Added: GetShortPath.diff ====================================================================== From rleigh at codelibre.net Tue Dec 22 15:24:58 2015 From: rleigh at codelibre.net (Roger Leigh) Date: Tue, 22 Dec 2015 20:24:58 +0000 Subject: [cmake-developers] CMakeFindDependencyMacro limitations In-Reply-To: References: <566DB6CA.1060801@codelibre.net> Message-ID: <5679B19A.80106@codelibre.net> On 21/12/2015 15:07, Stephen Kelly wrote: > Roger Leigh wrote: > >> I've run into a few limitations in find_dependency. I'm not sure if >> these are by design or could be fixed, so this is really a request for >> further explanation or design rationale. >> >> The first issue is this: >> >> if (NOT ${dep}_FOUND) >> >> This seems to be making the assumption that the found variable matches >> the dependency name, but the case used varies between modules and the >> name is case sensitive, from my reading of cmake-language. Is this >> correct? > > It is intentional, yes. See > > http://public.kitware.com/Bug/view.php?id=15412 > > The config-packages generated by cmake are canonical, so modules should set > the ExactCase_FOUND to be a 'correct module'. OK. >> The reason for stripping EXACT isn't clear. If my package has a strict >> requirement on another package, whether the caller has an exact >> requirement for the version of my package has no bearing on the >> requirements I have for my dependencies as far as I understand. What's >> the reason for the existing behaviour? > > I don't know what you are referring to with 'stripping EXACT'. Perhaps you > are looking at CMake < 3.0. See commit v3.0.0-rc2~10^2 (find_dependency: > Don't propagate EXACT argument., 2014-03-06). This one was me misreading the find_dependency macro--it's setting cmake_fd_exact_arg, so it is being passed. My mistake. >> I can understand why REQUIRED and related >> arguments are omitted--that is why find_dependency exists--but I'd quite >> like to be able to specify COMPONENTS where needed e.g. with FindBoost, >> and this is not currently possible. > > I don't remember whether this was discussed when designing find_dependency. > Perhaps COMPONENTS could be added to the macro now. > >> I was wondering if we could perhaps make find_dependency handle and pass >> through /all/ find_package arguments, minus REQUIRED/QUIET, so that >> find_dependency can expose the additional functionality offered by >> find_package. Some may not be useful, in which case they could be >> omitted, but some like COMPONENTS may be required for the find_package >> call to be useful. > > It might be possible, but might not be a good idea. What else do you want to > pass in? Currently, for my own needs, COMPONENTS is the single missing piece. If it would be possible to add this, it would certainly be very useful. The other arguments might be potentially useful, that was more of a general question of which other bits might have general utility in the context of calling find_dependency from a config script. I'd be happy to provide a patch for COMPONENTS if you like. Kind regards, Roger From mantis at public.kitware.com Tue Dec 22 20:00:21 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 22 Dec 2015 20:00:21 -0500 Subject: [cmake-developers] [CMake 0015893]: If cmake needs to restart due to changed compiler, it loses all command line variable assignments Message-ID: <4a0bf29c2530c7597d62f7780bb34f98@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15893 ====================================================================== Reported By: Paul Smith Assigned To: ====================================================================== Project: CMake Issue ID: 15893 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-12-22 20:00 EST Last Modified: 2015-12-22 20:00 EST ====================================================================== Summary: If cmake needs to restart due to changed compiler, it loses all command line variable assignments Description: If I invoke "cmake -DFOO=bar ." and cmake discovers that the compiler is changed and needs to re-invoke itself it does so automatically but in the process it loses all the -D options from the command line, so they're not set in the restart making it inaccurate. Steps to Reproduce: Given this CMakeLists.txt: cmake_minimum_required(VERSION 3.4.1) project(Restart NONE) set(BUILDNUM "0" CACHE STRING "Build Number") if(EXISTS "my/gcc") set(CMAKE_C_COMPILER "${CMAKE_CURRENT_BINARY_DIR}/my/gcc" CACHE FILEPATH "C compiler" FORCE) else() set(CMAKE_C_COMPILER "/usr/bin/gcc" CACHE FILEPATH "C compiler" FORCE) endif() message(STATUS "Build Number: ${BUILDNUM}") enable_language(C) Now run it once without the local "my" link, overridding BUILDNUM: $ cmake -DBUILDNUM=99 . -- Build Number: 99 -- The C compiler identification is GNU 5.2.1 -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Configuring done -- Generating done -- Build files have been written to: /home/psmith/src/cmake/restart Now create the symlink and run it again: it will change the compiler and restart: $ ln -s /usr/bin my $ cmake -DBUILDNUM=99 . -- Build Number: 99 -- Configuring done You have changed variables that require your cache to be deleted. Configure will be re-run and you may have to reset some variables. The following variables have changed: CMAKE_C_COMPILER= /home/psmith/src/cmake/restart/my/gcc -- Build Number: 0 -- The C compiler identification is GNU 5.2.1 -- Check for working C compiler: /home/psmith/src/cmake/restart/my/gcc -- Check for working C compiler: /home/psmith/src/cmake/restart/my/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Configuring done -- Generating done -- Build files have been written to: /home/psmith/src/cmake/restart Note how initially the value of BUILDNUM is 99, but then cmake decides to re-execute itself and afterwards that override is lost and we get the default value of "0". ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-12-22 20:00 Paul Smith New Issue ====================================================================== From mantis at public.kitware.com Wed Dec 23 08:04:58 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 23 Dec 2015 08:04:58 -0500 Subject: [cmake-developers] [CMake 0015894]: Visual C++ 2015 Generator wrong output for debug information Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15894 ====================================================================== Reported By: Thomas Laguzzi Assigned To: ====================================================================== Project: CMake Issue ID: 15894 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-12-23 08:04 EST Last Modified: 2015-12-23 08:04 EST ====================================================================== Summary: Visual C++ 2015 Generator wrong output for debug information Description: In 2015 there are three options to generate debug informations: None, Debug , Debug with fastlink (/DEBUG and /DEBUG:FASTLINK) The tag in the .vcxproj file doesn't take true or false anymore, instead it takes 3 values No Debug DebugFastLink depending on the option choosen, else you will see a wrong property value in the property sheet Note: it's not sufficient to add /DEBUG:FASTLINK to the additional options, it is ignored unless the .vcxproject file is correct. Steps to Reproduce: Just generate any Visual C++ project using Visual C++ 2015 (update 1). Additional Information: Tryed with Update 1 both 32 and 64bit. Don't know if previous versions have the same issue. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-12-23 08:04 Thomas Laguzzi New Issue ====================================================================== From mantis at public.kitware.com Wed Dec 23 10:50:34 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 23 Dec 2015 10:50:34 -0500 Subject: [cmake-developers] [CMake 0015895]: bootstrap compilation error Message-ID: <60c56db5b64412dcedb774e8a70da685@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15895 ====================================================================== Reported By: Burlen Assigned To: ====================================================================== Project: CMake Issue ID: 15895 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-12-23 10:50 EST Last Modified: 2015-12-23 10:50 EST ====================================================================== Summary: bootstrap compilation error Description: g++ -I/Users/bloring/apps/cmake/builds/cmake-3.4.1/Bootstrap.cmk -I/Users/bloring/apps/cmake/builds/cmake-3.4.1/Source -I/Users/bloring/apps/cmake/builds/cmake-3.4.1/Bootstrap.cmk -c /Users/bloring/apps/cmake/builds/cmake-3.4.1/Source/cmBootstrapCommands1.cxx -o cmBootstrapCommands1.o In file included from /usr/include/dispatch/dispatch.h:51:0, from /System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:15, from /System/Library/Frameworks/CoreFoundation.framework/Headers/CFPropertyList.h:13, from /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:55, from /Users/bloring/apps/cmake/builds/cmake-3.4.1/Source/cmFindProgramCommand.cxx:16, from /Users/bloring/apps/cmake/builds/cmake-3.4.1/Source/cmBootstrapCommands1.cxx:52: /usr/include/dispatch/object.h:143:15: error: expected unqualified-id before ?^? token typedef void (^dispatch_block_t)(void); ^ /usr/include/dispatch/object.h:143:15: error: expected ?)? before ?^? token /usr/include/dispatch/object.h:362:3: error: ?dispatch_block_t? has not been declared dispatch_block_t notification_block); ^ make: *** [cmBootstrapCommands1.o] Error 1 --------------------------------------------- Error when bootstrapping CMake: Problem while running make --------------------------------------------- Steps to Reproduce: ./configure && make ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-12-23 10:50 Burlen New Issue ====================================================================== From ewmailing at gmail.com Thu Dec 24 06:13:30 2015 From: ewmailing at gmail.com (Eric Wing) Date: Thu, 24 Dec 2015 03:13:30 -0800 Subject: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles Message-ID: Hi, This is kind of a continuation of the thread ?Adding Swift support to CMake?. Now that Swift is officially open source and already available for Linux, I started looking at the build process on Linux which I hope we can figure out how to incorporate into the CMake Makefile generator. To start with, there actually seem to be two different approaches. 1) The swiftc command line compiler (similar to gcc, clang with switches and output that seem to resemble them as well) 2) A formal package/module system for Swift which works with a Swift command line build tool ?swift build? So far, for my usage cases, I?ve found the (2) package/module system to be annoying and a bunch of indirection and extra steps. I also don?t feel I have completely wrapped my head around it, so I?m not going to focus on this for now. However, as more pure Swift libraries get written, I think interoperating with the module system will become extremely important, which we?ll ultimately need to deal with. But in the meantime, back to (1) swiftc, this I found much more straight-forward, at least for dealing with C code and C libraries and I think maps pretty well to the current CMake design. There is a pretty good example/write up found here: http://dev.iachieved.it/iachievedit/more-swift-on-linux/ For a Swift application that also has C code, and uses C libraries, this is the basic procedure: 1) Compile the C files into .o clang -c escapetext.c 2) Compile the Swift files into .o (note: The header seems to be the ?Bridging Header? discussed in the prior thread) swiftc -c escapeswift.swift -import-objc-header escapetext.h 3) Link all the object files together to build the final app executable swiftc escapeswift.o escapetext.o -o escapeswift -lcurl Here is another example I did with my own stuff which pushed a few edges, so I think it is instructive. - I am using a prebuilt SDL library on my system, but it is not a system installed component. - I defined extra C API functions for my SDL library to get around limitations in the automatic Swift/C binding. This is in SDLSwiftBinding.c - I have two swift files instead of one. (Note: ?main.swift? seems get special handling by the swift compiler and is always treated as your application entry point.) - I wanted to use -rpath $ORIGIN so I can ship my SDL library side-by-side with my application executable clang -I~/BlurrrSDKLinux/include/SDL2/ -c SDLSwiftBinding.c swiftc -c MyApp.swift main.swift -I~/BlurrrSDKLinux/include/SDL2/ -import-objc-header SwiftSDL-Bridging-Header.h -module-name MyProj swiftc main.o MyApp.o SDLSwiftBinding.o -o MyAppExe -Xlinker -rpath -Xlinker '$ORIGIN' -L~/BlurrrSDKLinux/lib -lSDL2 Note: I had to add -module-name MyProj because the compiler gave me an error without it. I think it is because I had multiple Swift files. I think for this case since I?m not making a library, I can use either the project or executable name. So I?d like to talk about how to further enhance CMake to do the above. In my head, for the above examples, I think I would want to do something like: find_package(SDL) include_directories(${SDL_INCLUDE_DIR}) # Forgot if we already had a convention for controlling this in the Xcode generator set(SWIFT_BRIDGING_HEADER SwiftSDL-Bridging-Header.h) add_executable(MyAppExe SDLSwiftBinding.c main.swift MyApp.swift ) target_link_libraries(MyAppExe ${SDL_LIBRARY}) # Do CMake rpath stuff as normal Thanks, Eric From steveire at gmail.com Thu Dec 24 07:07:08 2015 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 24 Dec 2015 13:07:08 +0100 Subject: [cmake-developers] CMakeFindDependencyMacro limitations References: <566DB6CA.1060801@codelibre.net> <5679B19A.80106@codelibre.net> Message-ID: Roger Leigh wrote: > On 21/12/2015 15:07, Stephen Kelly wrote: >> Roger Leigh wrote: >>> I can understand why REQUIRED and related >>> arguments are omitted--that is why find_dependency exists--but I'd quite >>> like to be able to specify COMPONENTS where needed e.g. with FindBoost, >>> and this is not currently possible. >> >> I don't remember whether this was discussed when designing >> find_dependency. Perhaps COMPONENTS could be added to the macro now. > > Currently, for my own needs, COMPONENTS is the single missing piece. If > it would be possible to add this, it would certainly be very useful. > > I'd be happy to provide a patch for COMPONENTS if you like. I think the reason that the macro does not support COMPONENTS is that I don't understand how COMPONENTS is supposed to work. For example: find_package(Qt5 COMPONENTS Widgets) # Is Qt5_FOUND set to true or false? find_package(Qt5 COMPONENTS Quick) # ... what about now? What does _FOUND ever mean if the find_package is called multiple times with different components? Does it mean anything? Should CMake disallow multiple use of find_package with the same package and with different components? If user code has find_package(Qt5 COMPONENTS Widgets) find_package(FooBar REQUIRED) and FooBarConfig.cmake has find_dependency(Qt5 COMPONENTS Quick) then the if(Qt5_FOUND) in the macro will mean it will not try to find the Quick component. So, there may be a need to establish a convention such as __FOUND and check that for each component in the macro. You would also need to think through everything and find out whether that is really a full solution. I haven't thought more deeply about it than the above. Note that the above example with Qt 5 can not currently happen in practice because the find_dependency macro does not support COMPONENTS, so config files must instead use find_dependency(Qt5Quick) if they want to use the macro currently. This is a good thing. So, I would like to know if * adding COMPONENTS support to the find_dependency macro is the right thing to do * or if the right thing to do is to move away from support for COMPONENTS generally because of its messy semantics * or if find_package should change to not support multiple calls for the same package. I really don't know the answer - I think someone needs to do deep thinking about it. I would prefer the macro not be changed before that deep thinking about COMPONENTS generally is done. Thanks, Steve. From ewmailing at gmail.com Thu Dec 24 07:46:15 2015 From: ewmailing at gmail.com (Eric Wing) Date: Thu, 24 Dec 2015 04:46:15 -0800 Subject: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles In-Reply-To: References: Message-ID: > set(SWIFT_BRIDGING_HEADER SwiftSDL-Bridging-Header.h) Quick addendum: Just realized the bridging header should probably be per-target. From domidimi at gmail.com Sun Dec 27 13:40:27 2015 From: domidimi at gmail.com (Dimitar Yordanov) Date: Sun, 27 Dec 2015 18:40:27 +0000 Subject: [cmake-developers] Profile Cmake scripts Message-ID: Hi all, I was searching for a way to profile CMake scripts in order to find bottlenecks and possibilities to improve performance. I found out that someone already invested time on that [1] providing a minimal solution. The idea behind it is to use the cmake "--trace" option and to output a time stamp and a stack depth with each executed command. The trace log is afterwards used by a Python script, which transforms it into a more readable format. In [1] there existed already a patch for CMake 2.8. This can be easily adapted for CMake 3.4. One of the issues with that approach is that the add_subdirectory() command creates a new stack and thus starts the depth count back from one again. I think it would be more appropriate to work around that in the Python script, which does the processing. A time stamp at the end of the whole execution would also be needed in order to calculate the time needed for the last command. Alternatively, the trace could output a time stamp at the beginning and at the end of each command. But that would produce larger traces. So, I would like to ask you for your opinion and if there is willingness to integrate such a patch in CMake. For the Python script itself I thought that it would maybe make sense to create an output in the Callgrind format. No idea if it is possible though. 1 - https://github.com/volo-zyko/cmake-profile-stats Regards, Dimitar -------------- next part -------------- An HTML attachment was scrubbed... URL: From neundorf at kde.org Sun Dec 27 15:05:53 2015 From: neundorf at kde.org (Alexander Neundorf) Date: Sun, 27 Dec 2015 21:05:53 +0100 Subject: [cmake-developers] Profile Cmake scripts In-Reply-To: References: Message-ID: <2657325.d8zfXOdkZG@tuxedo.neundorf.net> On Sunday, December 27, 2015 18:40:27 Dimitar Yordanov wrote: > Hi all, > > I was searching for a way to profile CMake scripts in order to find > bottlenecks and possibilities to improve performance. I found out that > someone already invested time on that [1] providing a minimal solution. The > idea behind it is to use the cmake "--trace" option and to output a time > stamp and a stack depth with each executed command. The trace log is > afterwards used by a Python script, which transforms it into a more > readable format. I actually simply used valgrind/callgrind and got useful results from that. Usually you see mostly string handling related functions. Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From domidimi at gmail.com Sun Dec 27 16:04:14 2015 From: domidimi at gmail.com (Dimitar Yordanov) Date: Sun, 27 Dec 2015 22:04:14 +0100 Subject: [cmake-developers] Profile Cmake scripts In-Reply-To: <2657325.d8zfXOdkZG@tuxedo.neundorf.net> References: <2657325.d8zfXOdkZG@tuxedo.neundorf.net> Message-ID: 2015-12-27 21:05 GMT+01:00 Alexander Neundorf : > > On Sunday, December 27, 2015 18:40:27 Dimitar Yordanov wrote: > > > Hi all, > > > > > > I was searching for a way to profile CMake scripts in order to find > > > bottlenecks and possibilities to improve performance. I found out that > > > someone already invested time on that [1] providing a minimal solution. The > > > idea behind it is to use the cmake "--trace" option and to output a time > > > stamp and a stack depth with each executed command. The trace log is > > > afterwards used by a Python script, which transforms it into a more > > > readable format. > > > > I actually simply used valgrind/callgrind and got useful results from that. I agree with you. Running valgrind directly on the cmake binary provides useful information: I can see which internal cmake functions are used the most and consume most of the time. Nevertheless, I think it would be useful to have a higher level overview. E.g. to see if there are some issues with the scripts themselves that I use in my project ... > Usually you see mostly string handling related functions. malloc and free are on the top of what I see for a random project used mostly by std::string. Maybe we can optimize something here too? Regards, Dimitar From mikko.koivunalho at iki.fi Mon Dec 28 07:31:56 2015 From: mikko.koivunalho at iki.fi (mikkoi) Date: Mon, 28 Dec 2015 13:31:56 +0100 Subject: [cmake-developers] FindSTLSoft.cmake, Problems? Message-ID: Hi, A CMake project depends on the header only library STLSoft (http://www.stlsoft.org/). We rely on the developer having STLSoft installed or "installed" (pointed to by an environment variable) on his system for compilation. To make sure the developer's version is high enough, I created this FindSTLSoft.cmake file. Can someone read it through, and say if there are any errors or antipatterns. I'm still learning CMake, so I might have made mistakes. Thank you. By the way, if it is good enough, it can be added to the CMake distribution. -- Mikko Koivunalho LinkedIn: http://www.linkedin.com/in/MikkoKoivunalho AboutMe: http://about.me/mikkokoivunalho Blog: http://exercisesinintegrationanddelivery.blogspot.com # - Find STLSoft # This module finds if STLSoft is installed and determines where the # include files and libraries are. This code sets the following # variables: # STLSOFT_FOUND - TRUE/FALSE - Found/not found (N.B. all upper case.) # STLSoft_INCLUDE_DIR - path to include # STLSoft_VERSION_MAJOR # STLSoft_VERSION_MINOR # STLSoft_VERSION_PATCH # STLSoft_VERSION # STLSoft_VERSION_COUNT # The minimum required version of STLSoft can be specified using the # standard CMake syntax, e.g. FIND_PACKAGE(STLSoft 1.9.117) # # Usage as follows: # find_package(STLSoft) # find_package(STLSoft 1.9.117 REQUIRED) # find_package(STLSoft 1.9.117 EXACT QUIET REQUIRED) #---------------------------------------------------------------------------------- include(FindPackageHandleStandardArgs) # try to get global environment variable first... set(_STLSOFT_ROOT "$ENV{STLSOFT}") if(_STLSOFT_ROOT) set(STLSoft_INCLUDE_DIR ${_STLSOFT_ROOT}/include) else(_STLSOFT_ROOT) find_path(STLSoft_INCLUDE_DIR NAMES stlsoft.h ) endif(_STLSOFT_ROOT) if(EXISTS "${STLSoft_INCLUDE_DIR}/stlsoft/stlsoft.h") file(READ "${STLSoft_INCLUDE_DIR}/stlsoft/stlsoft.h" _stlsoft_h_CONTENT) string(REGEX REPLACE ".*#define[ ]+_STLSOFT_VER_MAJOR[ ]+([0-9]+).*" "\\1" STLSoft_VERSION_MAJOR "${_stlsoft_h_CONTENT}") string(REGEX REPLACE ".*#define[ ]+_STLSOFT_VER_MINOR[ ]+([0-9]+).*" "\\1" STLSoft_VERSION_MINOR "${_stlsoft_h_CONTENT}") string(REGEX REPLACE ".*#define[ ]+_STLSOFT_VER_REVISION[ ]+([0-9]+).*" "\\1" STLSoft_VERSION_PATCH "${_stlsoft_h_CONTENT}") set(STLSoft_VERSION "${STLSoft_VERSION_MAJOR}.${STLSoft_VERSION_MINOR}.${STLSoft_VERSION_PATCH}") set(STLSoft_VERSION_COUNT 3) # Sets the STLSOFT_FOUND variable. find_package_handle_standard_args( STLSoft REQUIRED_VARS STLSoft_INCLUDE_DIR VERSION_VAR STLSoft_VERSION ) mark_as_advanced(STLSoft_INCLUDE_DIR STLSoft_VERSION_MAJOR STLSoft_VERSION_MINOR STLSoft_VERSION_PATCH STLSoft_VERSION STLSoft_VERSION_COUNT ) else(EXISTS "${STLSoft_INCLUDE_DIR}/stlsoft/stlsoft.h") if(NOT STLSoft_FIND_QUIETLY) message(FATAL_ERROR "No STLSoft package found... Please point us with the STLSOFT env var!") endif(NOT STLSoft_FIND_QUIETLY) endif(EXISTS "${STLSoft_INCLUDE_DIR}/stlsoft/stlsoft.h") From mantis at public.kitware.com Tue Dec 29 17:38:51 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 29 Dec 2015 17:38:51 -0500 Subject: [cmake-developers] [CMake 0015896]: Cmake does not find current hdf5 debug libraries Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15896 ====================================================================== Reported By: hevy Assigned To: ====================================================================== Project: CMake Issue ID: 15896 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-12-29 17:38 EST Last Modified: 2015-12-29 17:38 EST ====================================================================== Summary: Cmake does not find current hdf5 debug libraries Description: If you try to use the find hdf5 with only debug libraries from hdf5 1.8.16 it will not work. In deed, the find_library only look at libraries like: lib${LIB}d.a ${LIB}d for debug. But the current debug library from hdf5 have a prefix in "_D" for windows and "_debug" for Linux. Note: this is reproducible with older version like 3.1 ... ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-12-29 17:38 hevy New Issue ====================================================================== From gjasny at googlemail.com Wed Dec 30 08:33:08 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Wed, 30 Dec 2015 14:33:08 +0100 Subject: [cmake-developers] Anyone going to FOSDEM? Message-ID: <5683DD14.2040300@googlemail.com> Hello, I wonder if any of you CMake Developers go to FOSDEM [1] this year? Thanks, Gregor [1] https://fosdem.org/2016/ From cmake at eikel.org Wed Dec 30 09:54:26 2015 From: cmake at eikel.org (Benjamin Eikel) Date: Wed, 30 Dec 2015 15:54:26 +0100 Subject: [cmake-developers] Anyone going to FOSDEM? In-Reply-To: <5683DD14.2040300@googlemail.com> References: <5683DD14.2040300@googlemail.com> Message-ID: <2310101.S9Z750qJPX@horus> Hi Gregor, Am Mittwoch, 30. Dezember 2015, 14:33:08 schrieb Gregor Jasny via cmake- developers: > Hello, > > I wonder if any of you CMake Developers go to FOSDEM [1] this year? I am not a CMake developer, but, more or less, an advanced user, but I will go to FOSDEM next year. ;-) At least Stephen Kelly [2] will be there, too. Kind regards Benjamin [2] https://fosdem.org/2016/schedule/event/enabling_gui_tools_for_cmake_code/ From charles.huet at gmail.com Wed Dec 30 10:29:39 2015 From: charles.huet at gmail.com (Charles Huet) Date: Wed, 30 Dec 2015 15:29:39 +0000 Subject: [cmake-developers] Using CMake as a library from Python Message-ID: Hi, I'd like to have a discussion about using CMake as a library from python, and by that I mean not writing CMakeLists.txt files, but python code that then uses the CMake generators and Find*.cmake in order to leverage both the power of CMake and Python. First, a bit of background on the idea itself. I've used CMake since 2010 in different projects at work, and I love it. I'm the CMake guy at work, because most of the colleagues cannot be bothered with it. In fact I highly prefer doing the CMake maintenance myself, as most of the colleagues do not make any effort in trying to apply best practices of to factorize the code (which they do with the C++ code). When talking about CMake, the first reaction most of them have is about the language itself, because they don't know it, don't like some of the idioms, and have trouble accomplishing what they want with it. Nobody argues that CMake is awesome at generating either Visual Studio solutions or Unix Makefiles or whatever, but the language is a high barrier of entry. I have to admit that doing seemingly simple stuff can be a bit confusing in cmake, e.g. checking if the value of a variable is greater than another. Thus I thought that using a language that is well-known and has a closer syntax to what we are used to (not to mention we use python quite a bit for custom scripts) would greatly ease the maintenance of our buildsystem. This would allow for a few things that are not straightforward in cmake, such as functions that return a value. I prototyped around this idea these last weeks (a few minutes or hours at a time) and got it in a proof of concept state, where I cant do a add_library in python. I think this would be a great step forward for writing buildsystems, as lots of tasks would be greatly simplified. From the top of my mind: * reading files * writing files * downloading files * copying files (CMake's copy is not POSIX-compliant, as I learned recently when copying symbolic links) Also, the syntax could be made Object-Oriented very easily, as the python bindings will need a layer of abstraction. Now, for the technical realisation My prototype required a few modifications into CMake itself: * I added cmSystemTools::SetCMakeRoot, as the system root cannot be determined automatically using the current methods * cmLinkItem's typedef of std::string was made public because swig has trouble with it. There may be a better way to solve the problem, but this was the quickest for a POC * cmCacheManager::AddCacheEntry was made public, as cmake::Configure cannot be used from python (it check for the existence of a CMakeLists.txt file, which does not exist in this scenario) and the cache variables it sets seem to be necessary. A cmake.i swig interface file, and a python file that does the initialization of CMake, and I have a simple library compiled. I will try to make a layer of abstraction on top of the python bindings before publishing this work on github, in order to show the syntactic sugar python can provide, but I will publish this before if anybody is interested in working on this. Now, does anyone beside me think this is a good idea ? Cheers -------------- next part -------------- An HTML attachment was scrubbed... URL: