Re: [cmake-developers] Fw: 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 BaratovSent: Thursday, December 3, 2015 11:06 AM To: Bartosz Kosiorek Cc: Gregor Jasny; cmake-developers@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@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 >
Re: [cmake-developers] Fw: Please comment on ios-universal topic
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@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 BaratovSent: Thursday, December 3, 2015 11:06 AM To: Bartosz Kosiorek Cc: Gregor Jasny; cmake-developers@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@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
Re: [cmake-developers] Fw: 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 BaratovSent: Thursday, December 3, 2015 4:09 AM To: Bartosz Kosiorek Cc: Gregor Jasny; cmake-developers@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:
Re: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation
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 Johnstonwrote: >> -Original Message- > >> From: cmake-developers [mailto:cmake-developers-boun...@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
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
Re: [cmake-developers] [PATCH] Fix Resource directory structure for iOS Bundles (Framework and Application), update Tests and Help
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 -- 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] Various Java support enhancements
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 -- 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] [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 -- 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] [PATCH] Extend copy and copy_if_different commands with support multiple files
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 KingSent: Thursday, December 3, 2015 5:38 PM To: Bartosz Kosiorek Cc: cmake-developers@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 -- 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] [PATCH] Extend copy and copy_if_different commands with support multiple files
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-developerson behalf of Brad King Sent: Thursday, December 3, 2015 2:45 PM To: cmake-developers@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 -- 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
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 -- 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 0015871]: Cmake may select incorrect default generator on windows host
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 ModifiedUsername FieldChange == 2015-12-03 17:13 Richard Lang 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] [PATCH] Extend copy and copy_if_different commands with support multiple files
Hello. Here is the patch with tests. From: Brad KingSent: Thursday, December 3, 2015 7:07 PM To: Bartosz Kosiorek Cc: cmake-developers@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 From 8225688074386ac8633bad5e6f9fdb4a7caf9775 Mon Sep 17 00:00:00 2001 From: "Bartosz Kosiorek bartosz.kosio...@tomtom.com" Date: Thu, 3 Dec 2015 00:43:37 +0100 Subject: [PATCH 1/2] Extend copy and copy_if_different command with support multiple files This patch allows to use multiple files in command copy and copy_if_different. Input files could be merged with wildcards. If multipile input files were provided, then destination must be directory. If only one input file was provided, then destination could be either file or directory. This path is starting point for fixing bug 15703 --- Help/manual/cmake.1.rst | 12 Source/cmcmd.cxx| 73 +++-- 2 files changed, 58 insertions(+), 27 deletions(-) diff --git a/Help/manual/cmake.1.rst b/Help/manual/cmake.1.rst index dac16bf..086f259 100644 --- a/Help/manual/cmake.1.rst +++ b/Help/manual/cmake.1.rst @@ -169,14 +169,14 @@ Available commands are: ``compare_files `` Check if file1 is same as file2. -``copy `` - Copy file to destination (either file or directory). +``copy ... `` + Copy files to 'destination' (either file or directory). ``copy_directory `` Copy directory 'source' content to directory 'destination'. -``copy_if_different `` - Copy file if input has changed. +``copy_if_different ... `` + Copy files if input has changed. Destination could be file or directory. ``echo [...]`` Displays arguments as text. @@ -193,10 +193,10 @@ Available commands are: ``make_directory `` Create a directory. -``md5sum [...]`` +``md5sum ...`` Compute md5sum of files. -``remove [-f] [...]`` +``remove [-f] ...`` Remove the file(s), use ``-f`` to force it. ``remove_directory `` diff --git a/Source/cmcmd.cxx b/Source/cmcmd.cxx index 21b126b..0dc5a9a 100644 --- a/Source/cmcmd.cxx +++ b/Source/cmcmd.cxx @@ -52,25 +52,25 @@ void CMakeCommandUsage(const char* program) // If you add new commands, change here, // and in cmakemain.cxx in the options table errorStream -<< "Usage: " << program << " -E [command] [arguments ...]\n" +<< "Usage: " << program << " -E [arguments...]\n" << "Available commands: \n" << " chdir dir cmd [args]... - run command in a given directory\n" << " compare_files file1 file2 - check if file1 is same as file2\n" -<< " copy file destination - copy file to destination (either file " - "or directory)\n" +<< " copy ... destination - copy files to destination " + "(either file or directory)\n" << " copy_directory source destination - copy directory 'source' " "content to directory 'destination'\n" -<< " copy_if_different in-file out-file - copy file if input has " +<< " copy_if_different ... destination - copy files if it has " "changed\n" -<< " echo [string]... - displays arguments as text\n" -<< " echo_append [string]... - displays arguments as text but no new " +<< " echo [...]- displays arguments as text\n" +<< " echo_append [...] - displays arguments as text but no new " "line\n" << " 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" -<< " md5sum file1 [...]- compute md5sum of files\n" -<< " remove [-f] file1 file2 ... - remove the file(s), use -f to force " +<< " md5sum ... - compute md5sum of files\n" +<< " remove [-f] ... - remove the file(s), use -f to force " "it\n" << " remove_directory dir - remove a directory and its contents\n" << " rename oldname newname- rename a file or directory " @@ -78,7 +78,7 @@ void CMakeCommandUsage(const char* program) << " tar [cxt][vf][zjJ] file.tar [file/dir1 file/dir2
Re: [cmake-developers] [PATCH] FindTIFF: Add imported targets
On 02/12/2015 17:31, rle...@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 g...@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 -- 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] [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