Re: [cmake-developers] Please comment on ios-universal topic
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 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] set(CACHE) and the local scope
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 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015876]: "Cannot restore timestamp"
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 ModifiedUsername FieldChange == 2015-12-09 15:38 A. Jesse Jiryu DavisNew Issue == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] Support multiple directories by "cmake -E make_directory" command
Hello. With following patch, I have added support for multiple directories for make_directory command. ?Best Regards Bartosz From e189db26e60254712e3e73a11296c58d8f61fe68 Mon Sep 17 00:00:00 2001 From: Bartosz Kosiorek Date: Wed, 9 Dec 2015 15:59:43 +0100 Subject: [PATCH] Extend make_directory command to support multiple directories --- Help/manual/cmake.1.rst | 9 + Source/cmcmd.cxx | 19 --- .../E_make_directory-directory-with-parent-result.txt | 1 + .../E_make_directory-directory-with-parent-stderr.txt | 0 ...ke_directory-three-directories-and-file-result.txt | 1 + ...ke_directory-three-directories-and-file-stderr.txt | 1 + .../E_make_directory-three-directories-result.txt | 1 + .../E_make_directory-three-directories-stderr.txt | 0 Tests/RunCMake/CommandLine/RunCMakeTest.cmake | 14 ++ 9 files changed, 35 insertions(+), 11 deletions(-) create mode 100644 Tests/RunCMake/CommandLine/E_make_directory-directory-with-parent-result.txt create mode 100644 Tests/RunCMake/CommandLine/E_make_directory-directory-with-parent-stderr.txt create mode 100644 Tests/RunCMake/CommandLine/E_make_directory-three-directories-and-file-result.txt create mode 100644 Tests/RunCMake/CommandLine/E_make_directory-three-directories-and-file-stderr.txt create mode 100644 Tests/RunCMake/CommandLine/E_make_directory-three-directories-result.txt create mode 100644 Tests/RunCMake/CommandLine/E_make_directory-three-directories-stderr.txt diff --git a/Help/manual/cmake.1.rst b/Help/manual/cmake.1.rst index 4cbe976..3cd7888 100644 --- a/Help/manual/cmake.1.rst +++ b/Help/manual/cmake.1.rst @@ -167,7 +167,8 @@ Available commands are: Change the current working directory and run a command. ``compare_files `` - Check if file1 is same as file2. + Check if is same as . If files are the same, + then returns 0, if not itreturns 1. ``copy ... `` Copy files to (either file or directory). @@ -194,10 +195,10 @@ Available commands are: Run command in a modified environment. ``environment`` - Display the current environment. + Display the current environment variables. -``make_directory `` - Create a directory. +``make_directory ...`` + Create parent and directories. ``md5sum ...`` Compute md5sum of files. diff --git a/Source/cmcmd.cxx b/Source/cmcmd.cxx index 6a4234f..fb7b1f5 100644 --- a/Source/cmcmd.cxx +++ b/Source/cmcmd.cxx @@ -68,7 +68,7 @@ void CMakeCommandUsage(const char* program) << " env [--unset=NAME]... [NAME=VALUE]... COMMAND [ARG]...\n" << "- run command in a modified environment\n" << " environment - display the current environment\n" -<< " make_directory dir- create a directory\n" +<< " make_directory ... - create parent and directories\n" << " md5sum ... - compute md5sum of files\n" << " remove [-f] ... - remove the file(s), use -f to force " "it\n" @@ -447,15 +447,20 @@ int cmcmd::ExecuteCMakeCommand(std::vector& args) } #endif -else if (args[1] == "make_directory" && args.size() == 3) +else if (args[1] == "make_directory" && args.size() > 2) { - if(!cmSystemTools::MakeDirectory(args[2].c_str())) + // If error occurs we want to continue copying next files. + bool return_value = 0; + for (std::string::size_type cc = 2; cc < args.size(); cc ++) { -std::cerr << "Error making directory \"" << args[2] - << "\".\n"; -return 1; +if(!cmSystemTools::MakeDirectory(args[cc].c_str())) + { + std::cerr << "Error creating directory \"" +<< args[cc] << "\".\n"; + return_value = 1; + } } - return 0; + return return_value; } else if (args[1] == "remove_directory" && args.size() == 3) diff --git a/Tests/RunCMake/CommandLine/E_make_directory-directory-with-parent-result.txt b/Tests/RunCMake/CommandLine/E_make_directory-directory-with-parent-result.txt new file mode 100644 index 000..573541a --- /dev/null +++ b/Tests/RunCMake/CommandLine/E_make_directory-directory-with-parent-result.txt @@ -0,0 +1 @@ +0 diff --git a/Tests/RunCMake/CommandLine/E_make_directory-directory-with-parent-stderr.txt b/Tests/RunCMake/CommandLine/E_make_directory-directory-with-parent-stderr.txt new file mode 100644 index 000..e69de29 diff --git a/Tests/RunCMake/CommandLine/E_make_directory-three-directories-and-file-result.txt b/Tests/RunCMake/CommandLine/E_make_directory-three-directories-and-file-result.txt new file mode 100644 index 000..d00491f --- /dev/null +++ b/Tests/RunCMake/CommandLine/E_make_directory-three-directories-and-file-result.txt @@ -0,0 +1 @@ +1 diff --git a/Tests/RunCMake/CommandLine/E_make_directory-three-directories-and-file-stderr.txt b/Tests/RunCMake/CommandL
Re: [cmake-developers] Proposal to teach cmDepends to only take dependencies from the source tree
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 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015875]: CMake does not find the VS2015 C compiler even though it has been installed by building a C/C++ program
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 ModifiedUsername FieldChange == 2015-12-09 10:57 philrosenberg New Issue == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake][PATCH] AIX RPATH handling
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
Re: [cmake-developers] Proposal to teach cmDepends to only take dependencies from the source tree
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 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake][PATCH] AIX RPATH handling
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
Re: [cmake-developers] [CMake][PATCH] AIX RPATH handling
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 > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake][PATCH] AIX RPATH handling
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 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Add command line options for deprecation message control
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 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Keil Armcc support
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 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake][PATCH] AIX RPATH handling
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 0001-AIX-fix-erroneous-RPATH-handling-for-executables.patch Description: 0001-AIX-fix-erroneous-RPATH-handling-for-executables.patch -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Keil Armcc support
Hi, Is theresomme support planned in a near future for the Keil / Armcc toolchain ? Regards, Yann Suisini -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Please comment on ios-universal topic
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 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Proposal to teach cmDepends to only take dependencies from the source tree
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 > -- 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