Re: [cmake-developers] [PATCH] Add a test for checking that the CPack module produces correct config files
Hi, I apologise for the late reply. I wasn't at my computer for the past week. 2015-08-19 21:08 GMT+02:00 Роман Донченко d...@corrigendum.ru: Currently, the only case is for simple variable values (not containing any CMake-special characters and not determined by CPack itself). In CPackRPM and CPackDeb both cases that this is testing (CMake list variable and a variable containing spaces) are already tested implicitly. RunCMake.CPack contains such test. Admittedly both cases are not present in same variable. Your test passes on my computer. Is this test targeting a particular CPack generator or a CMake-CPack bug on a particular OS? Regards, Domen -- 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] Fixing bug #12506 (iOS install)
Hallo,
On 13/08/15 12:56, Ruslan Baratov wrote:
On 13-Aug-15 08:46, Gregor Jasny wrote:
On 13/08/15 01:44, Ruslan Baratov via cmake-developers wrote:
Sending patches with fix. Now it's possible to install simulator
libraries by:
cmake --build _builds --config Release --target install -- -sdk
iphonesimulator
and device libraries by:
cmake --build _builds --config Release --target install -- -sdk
iphoneos
or from Xcode IDE (build target install).
However this commands will install both libraries to the same location.
This behaviour can be improved by adding some code that will do lipo of
all libraries before install (i.e. universal libraries will be
installed). This can be achieved by using ONLY_ACTIVE_ARCHS=NO while
running Xcode build. The only question is about making install target
depends on two type of builds (-sdk iphonesimulator and -sdk iphoneos).
This was my preliminary work:
https://github.com/gjasny/CMake/commit/978dca25ac387bdec894a1ba2c934317f5f6169f
This looks great! I've spent several hours trying to figure out how
'$(EFFECTIVE_PLATFORM_NAME)' can be set to Xcode and some CMake friendly
string to cmake_install.cmake script. I didn't know Xcode understand
`${VAR}` syntax (probably it didn't, it's just expanded as an
environment variable). I've tested your fix and it works fine for me.
Since we don't need to replace string with path manually I think your
solution is neater. I've added description to commit and rebased it, see
attachment.
I just pushed the fix-ios-install topic including a test. Basically the
patch changes the invocation line of the script from
cmake -DBUILD_TYPE=Release-iphoneos -P cmake_install.cmake
to
cmake -DBUILD_TYPE=Release -DEFFECTIVE_PLATFORM_NAME=-iphoneos -P
cmake_install.cmake
and within the install script
file(INSTALL DESTINATION ${CMAKE_INSTALL_PREFIX}/lib TYPE
STATIC_LIBRARY FILES .../Release/libfoo.a)
to
file(INSTALL DESTINATION ${CMAKE_INSTALL_PREFIX}/lib TYPE
STATIC_LIBRARY FILES .../Release${EFFECTIVE_PLATFORM_NAME}/libfoo.a)
By keeping the ${EFFECTIVE_PLATFORM_NAME} a variable one is able to use
the same install script for iphoneos and iphonesimulator SDKs.
Please review and merge.
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
Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens
I agree with David. Offering the possibility to manage native paths in an easy way is a very good enhancement (Today, I rely on some specific actions when I am on Win32 to manage native path for ONE specific step of ExternalProject) BUT, offering only the alternative to have NONE or ALL paths in native form is, by far, too restrictive. So I am for the solution providing new patterns as alternative to current ones to manage native paths, i.e. Adding *_NATIVE_DIR for all already available *_DIR patterns. Marc On 25/08/15 17:31, cmake-developers on behalf of David Cole via cmake-developers cmake-developers-boun...@cmake.org on behalf of cmake-developers@cmake.org wrote: I'm going to let other CMake developers chime in on this one. It's better than the first patch, because it's opt-in, and you have to add something to get different than previous behavior, but I'm still of the opinion that this is very command specific, and you won't always want all _DIR references as native. In my opinion, it's better left to the person constructing the ExternalProject_Add call. But I am curious to hear other CMake devs give their opinions. David C. On Tue, Aug 25, 2015 at 3:18 AM, Kislinskiy, Stefan s.kislins...@dkfz-heidelberg.de wrote: Dear CMake developers, any thoughts on the fix? :) Best regards, Stefan Kislinskiy Von: cmake-developers [cmake-developers-boun...@cmake.org] im Auftrag von Kislinskiy, Stefan [s.kislins...@dkfz-heidelberg.de] Gesendet: Freitag, 21. August 2015 23:56 An: David Cole; James Johnston Cc: cmake-developers@cmake.org Betreff: Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens What do you think about the new patch I attached to this mail? It adds an option NATIVE_DIR_TOKENS to ExternalProjects_Add. I also attached a CMake script file which tests/shows this feature. Stefan Kislinskiy Von: cmake-developers [cmake-developers-boun...@cmake.org] im Auftrag von David Cole via cmake-developers [cmake-developers@cmake.org] Gesendet: Donnerstag, 20. August 2015 23:20 An: James Johnston Cc: cmake-developers@cmake.org Betreff: Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens It's exactly what I am concerned about: You're asking to change the behavior of something for EVERYONE to solve a problem which you have encountered. If you change it the way you have proposed, you will cause problems for others. It has worked the way it is now since ExternalProject_Add was introduced in CMake 2.8. Changing it unconditionally the way you propose is simply not feasible for backwards compatibility. I think commands that take native paths ought NOT to use the *_DIR replacement values, and instead, ought to pass in variables that contain the native paths in the first place. David C. On Thu, Aug 20, 2015 at 2:58 PM, James Johnston johnstonj.pub...@codenest.com wrote: Hi, Funny you are mailing the list about this, since I just ran into this same issue today building something totally different from Boost... In this case it's a build tool that thinks the /U in C:/Users is a new command line argument, that isn't recognized - and then the subsequent s also ends up unrecognized... and it all fails... And it has nothing to do with the working directory, so _Add_Step(WORKING_DIRECTORY) isn't a possible workaround for me. I think the issue with globally making this change to the existing tokens is that there could be some external tool/program that is EXPECTING to get CMake paths, not native paths. Who knows? I am guessing that is what David Cole was concerned about. Maybe the right answer is to introduce some NEW tokens while leaving the behavior of the old ones unchanged. E.g. BINARY_DIR_NATIVE etc. It would be good if the patch updates the documentation of ExternalProject and clearly states the path format of BINARY_DIR vs BINARY_DIR_NATIVE. Then the user can pick whichever one suits them best, depending on the tool being invoked. Furthermore, sometimes BINARY_DIR_NATIVE still needs to be replaced with a CMake path, not native path. For example, if the token is being found in a property like WORKING_DIRECTORY that eventually gets passed to add_custom_command(WORKING_DIRECTORY) then I'm guessing still has to be a CMake path. I am guessing this is what David Cole was also concerned about. I still think your original method of building Boost is a bit unusual and would be better served by _Add_Step with a custom working directory - because that's the publicly documented/standard way of changing the working directory, but that is up to you. :) Best regards, James Johnston On Thu, 20 Aug 2015 14:37:08 + Stefan Kislinskiy s.kislins...@dkfz-heidelberg.de wrote Hi, thank you for our suggestions. I am aware
Re: [cmake-developers] Xcode 7 tbd library stub support
On 25/08/15 19:01, Brad King wrote: On 08/24/2015 04:43 PM, Gregor Jasny via cmake-developers wrote: I just pushed a topic branch to add support for Xcode 7 TDB files: http://www.cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/apple-tbd-stubs Thanks. Please merge to 'next' when ready. Test looks good: -- XcodeFileType - PASSED -- XcodeAttributeGenex - PASSED -- XcodeAttributeGenexError - PASSED -- XcodeObjectNeedsQuote - PASSED -- XcodePlatformFrameworks - PASSED -- XcodeBundles - PASSED -- XcodeBundles-build - PASSED -- XcodeBundles - PASSED -- XcodeBundles-build - PASSED -- XcodeTbdStub - PASSED https://open.cdash.org/testDetails.php?test=366644123build=3974796 -- 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] New policy to address rdynamic
Chuck Atkins wrote: I've implemented a new policy, CMP0065, to restrict the addition of CMAKE_SHARED_LIBRARY_LINK_LANG_FLAGS to executables to only when the ENABLE_EXPORTS target property is set. This should allow us to preserve backwards compatibility in the places it breaks existing binaries but allow us to remove it by default for newer projects. See stage/restrict-shlib-link-flags-to-enable-exports The motivator behind this is to get closer to easily supporting fully static binaries.. Any feedback would be appreciated. You add an [ENABLE_EXPORTS] keyword to try_compile. Maybe [TARGET_PROPERTIES prop1 value1 [prop1 value1]... ] makes sense instead? That would allow setting ANDROID_API, WIN32_EXECUTABLE etc. Thanks, Steve. -- 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/CPack Docker Integration
Dear all, We have received funding from the Greek Free/Open Source Software Society https://ellak.gr/greek-free-open-source-software-societygfoss/ to develop Docker integration to CMake and CPack. As a first step, we have created a simple questionaire for collecting user and developer input towards the features that would be most useful. We would appreciate it if you could spend some time to answer it by following this link http://goo.gl/forms/H3716MlS0o. It will take less than 5 minutes of your time and your feedback is valuable. Thank you very much, Best regards, Aris Synodinos Konstantinos Chatzilygeroudis -- 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 0015713]: CMake generates “-L/usr/local/lib” on Mac OSX
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15713 == Reported By:ovz Assigned To: == Project:CMake Issue ID: 15713 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2015-08-26 18:28 EDT Last Modified: 2015-08-26 18:28 EDT == Summary:CMake generates “-L/usr/local/lib” on Mac OSX Description: Could you please help me with the question I asked on the mailing list. http://public.kitware.com/pipermail/cmake/2015-August/061413.html. The question is also pasted into Steps to Reproduce for convenience. I'm still at loss what triggers CMake to generate -L/usr/local/lib linker flag. Steps to Reproduce: I have a CMake C++ dylib project that builds correctly in one MacOS X environment but fails in another. Environments are on the same machine, but under different users. I'm seeking help how to do I troubleshoot where the failure in the second one comes from.What I managed to figure out is that in failing configuration CMake adds the following flags in link.txt (the commands used to link the executable)-arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -mmacosx-version-min=10.6 -L/usr/local/lib The last one causes havoc as it makes ld pick up dependencies from /usr/local/lib instead of link directories I configured in CMake.I would appreciate any insight what triggers generating the flags above and what is the best way to squelch them, especially -L/usr/local/lib? == Issue History Date ModifiedUsername FieldChange == 2015-08-26 18:28 ovzNew 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] [CPack] CPackDeb and fakeroot
Hi, I see that I'm a bit late to the party... Wasn't at my computer for the past few days. Now if you find a way to set root ownership in archive created by CPackDeb then every deb package will have those right. Again two solutions: - using system tar with the proper uid/gid options - using and tweaking libarchive directly I haven't used uid/gid options in libarchive so I'm not certain what it's capabilities are but if possible I'd definitely go with libarchive. My opinion (from the various bug report related to deb ownership) is that is OK since creating a deb including whatever non-root user in it is a mistake. I agree. So the proper way to go may be to use libarchive directly in CPackDeb to create tar in order to better control ownership of the created bits. This is definitely more work, but this looks the proper way to me. Ok, I just had a look to the cmlibarchive, cmakelib and cpackdeb sources, it's not such a big deal neither to support that functionality. One question remains though: in case of lzma or xy compression, cmake -E tar is not used, and system tar is used instead (lines 414 in cmCPackDebGenerator.cxx). This looks different from what you mentioned about the BSD ar format using ar_append at the end of the same function. LZMA and xy are supported by libarchive, so it should be possible to avoid any call to tar or cmake -E in all cases. Since lzma and xz are also using fakeroot and for consistency I'd go with with libarchive here as well. I'm guessing that the only reason these two compression formats were treated as special cases was because of lack of support in CMake in the past: http://www.cmake.org/Bug/view.php?id=13072 but this was resolved more than a year ago. Regards, Domen -- 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] nvidia nsight tegra set vcxproj properties (Ant Build) in cmake file
Awesome - in that case I'll use this built-in support instead of spending time on writing a python script to call from add_custom_command(). It's not officially documented yet ( http://bit.ly/1MOzB0S ), but I can use the link you sent ( http://bit.ly/1UdL3nc ) for documentation. I'm not sure whether this is in the CMake 3.3.1 release, but if not then I can try a nightly build: http://www.cmake.org/download/ - http://www.cmake.org/files/dev/?C=M;O=D - cmake-3.3.20150824-ga3d05-win32-x86.exe Or if that doesn't work, then maybe I'll wait a few days and try a newer nightly build :-) thank you, Peter PS: I love this built-in (nvidia tegra nsight + visual studio 2010) support... Some similar things that would also be awesome as built-in support are... nvidia tegra nsight + visual studio 2013, 2015. nmake + Android Studio (Windows, Mac, Linux). iOS + XCode. On Wed, Aug 26, 2015 at 7:15 AM, Dmitry Polyanitsa dpolyani...@nvidia.com wrote: Hi Peter, Note the commit Brad mentioned in another thread: VS: Add more Nsight Tegra generator Android property settings http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8c0afaf4 It adds the ability to set both Native Library Directories and Native Library Dependencies, among other things. Thanks for the link to the forum post, by the way – we forgot to update it and will do that now. -Dmitry *From:* cmake-developers [mailto:cmake-developers-boun...@cmake.org] *On Behalf Of *Peter List *Sent:* Wednesday, August 26, 2015 5:06 AM *To:* cmake-developers@cmake.org *Subject:* [cmake-developers] nvidia nsight tegra set vcxproj properties (Ant Build) in cmake file I have a working hello world cmake + built-in Android using nvidia nsight tegra. It uses SDL2. Unfortunately, after I run cmake I have to manually edit the following in my vcxproj to add SDL2: Configuration Properties Ant Build Native Library Directories, Native Library Dependencies I found this post ( http://bit.ly/1NTgTE3 ) from May 5th (3 months 20 days ago) describing the same issue. Is there an ETA on this? Since this isn't out yet, is there a work-around I can do instead? So far my best idea is to have cmake use add_custom_command() as a post-build step to call a python script that edits the vcxproj file XML. AntBuild AntBuildPath[path]\build-android\android-project/AntBuildPath AndroidManifestLocation[path]\build-android\android-project\AndroidManifest.xml/AndroidManifestLocation NativeLibDirectories../../../SDL2-2.0.3/libs/armeabi-v7a/NativeLibDirectories NativeLibDependenciesSDL2/NativeLibDependencies /AntBuild thank you -- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -- -- 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] ExternalProject: Use native paths as substitute for directory tokens
Would you prefer to have a switch for each *_DIR variable for all target steps, or a common switch but for each target step, like the new USE_TERMINAL switches in the master? Von: CHEVRIER, Marc [marc.chevr...@sap.com] Gesendet: Mittwoch, 26. August 2015 08:49 An: David Cole; Kislinskiy, Stefan Cc: cmake-developers@cmake.org Betreff: Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens I agree with David. Offering the possibility to manage native paths in an easy way is a very good enhancement (Today, I rely on some specific actions when I am on Win32 to manage native path for ONE specific step of ExternalProject) BUT, offering only the alternative to have NONE or ALL paths in native form is, by far, too restrictive. So I am for the solution providing new patterns as alternative to current ones to manage native paths, i.e. Adding *_NATIVE_DIR for all already available *_DIR patterns. Marc On 25/08/15 17:31, cmake-developers on behalf of David Cole via cmake-developers cmake-developers-boun...@cmake.org on behalf of cmake-developers@cmake.org wrote: I'm going to let other CMake developers chime in on this one. It's better than the first patch, because it's opt-in, and you have to add something to get different than previous behavior, but I'm still of the opinion that this is very command specific, and you won't always want all _DIR references as native. In my opinion, it's better left to the person constructing the ExternalProject_Add call. But I am curious to hear other CMake devs give their opinions. David C. On Tue, Aug 25, 2015 at 3:18 AM, Kislinskiy, Stefan s.kislins...@dkfz-heidelberg.de wrote: Dear CMake developers, any thoughts on the fix? :) Best regards, Stefan Kislinskiy Von: cmake-developers [cmake-developers-boun...@cmake.org] im Auftrag von Kislinskiy, Stefan [s.kislins...@dkfz-heidelberg.de] Gesendet: Freitag, 21. August 2015 23:56 An: David Cole; James Johnston Cc: cmake-developers@cmake.org Betreff: Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens What do you think about the new patch I attached to this mail? It adds an option NATIVE_DIR_TOKENS to ExternalProjects_Add. I also attached a CMake script file which tests/shows this feature. Stefan Kislinskiy Von: cmake-developers [cmake-developers-boun...@cmake.org] im Auftrag von David Cole via cmake-developers [cmake-developers@cmake.org] Gesendet: Donnerstag, 20. August 2015 23:20 An: James Johnston Cc: cmake-developers@cmake.org Betreff: Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens It's exactly what I am concerned about: You're asking to change the behavior of something for EVERYONE to solve a problem which you have encountered. If you change it the way you have proposed, you will cause problems for others. It has worked the way it is now since ExternalProject_Add was introduced in CMake 2.8. Changing it unconditionally the way you propose is simply not feasible for backwards compatibility. I think commands that take native paths ought NOT to use the *_DIR replacement values, and instead, ought to pass in variables that contain the native paths in the first place. David C. On Thu, Aug 20, 2015 at 2:58 PM, James Johnston johnstonj.pub...@codenest.com wrote: Hi, Funny you are mailing the list about this, since I just ran into this same issue today building something totally different from Boost... In this case it's a build tool that thinks the /U in C:/Users is a new command line argument, that isn't recognized - and then the subsequent s also ends up unrecognized... and it all fails... And it has nothing to do with the working directory, so _Add_Step(WORKING_DIRECTORY) isn't a possible workaround for me. I think the issue with globally making this change to the existing tokens is that there could be some external tool/program that is EXPECTING to get CMake paths, not native paths. Who knows? I am guessing that is what David Cole was concerned about. Maybe the right answer is to introduce some NEW tokens while leaving the behavior of the old ones unchanged. E.g. BINARY_DIR_NATIVE etc. It would be good if the patch updates the documentation of ExternalProject and clearly states the path format of BINARY_DIR vs BINARY_DIR_NATIVE. Then the user can pick whichever one suits them best, depending on the tool being invoked. Furthermore, sometimes BINARY_DIR_NATIVE still needs to be replaced with a CMake path, not native path. For example, if the token is being found in a property like WORKING_DIRECTORY that eventually gets passed to add_custom_command(WORKING_DIRECTORY) then I'm guessing still has to be a CMake path. I am guessing this is what David Cole was also
Re: [cmake-developers] [CPack] CPackDeb and fakeroot
Le 26/08/15 01:07, Eric Noulard a écrit : Right, but I am more concerned about the proper way of doing it and not the difficulty. From all this discussion, using fakeroot directly does not look to me as the right solution for having root in the tar, in the first place. So if we are also able to get rid of the fakeroot machinery in cpack, maybe it would be a better solution. I agree, then the question is should every deb package built by CPack being owned by root? Currently people making deb with CPack without having fakeroot installed get their package with current user owning. i.e. fakeroot is not ALWAYS used. Ok, but the created packages are not debian compliant, so we cannot really say that the generated artifacts are Debian packages. Now if you find a way to set root ownership in archive created by CPackDeb then every deb package will have those right. Again two solutions: - using system tar with the proper uid/gid options - using and tweaking libarchive directly My opinion (from the various bug report related to deb ownership) is that is OK since creating a deb including whatever non-root user in it is a mistake. I agree. So the proper way to go may be to use libarchive directly in CPackDeb to create tar in order to better control ownership of the created bits. This is definitely more work, but this looks the proper way to me. Ok, I just had a look to the cmlibarchive, cmakelib and cpackdeb sources, it's not such a big deal neither to support that functionality. One question remains though: in case of lzma or xy compression, cmake -E tar is not used, and system tar is used instead (lines 414 in cmCPackDebGenerator.cxx). This looks different from what you mentioned about the BSD ar format using ar_append at the end of the same function. LZMA and xy are supported by libarchive, so it should be possible to avoid any call to tar or cmake -E in all cases. Raffi -- 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] ExternalProject: Use native paths as substitute for directory tokens
I see. Added native-style path replacements for SOURCE_NATIVE_DIR and so on.
Also extended the documentation accordingly.
Von: CHEVRIER, Marc [marc.chevr...@sap.com]
Gesendet: Mittwoch, 26. August 2015 10:26
An: Kislinskiy, Stefan; David Cole
Cc: cmake-developers@cmake.org
Betreff: Re: AW: [cmake-developers] ExternalProject: Use native paths as
substitute for directory tokens
I didn’t even think about switches. I don’t think they are required.
Adding the capability to handle paths in native format seems enough.
Example: I want to use a specific tool for the build step which supports only
native paths
ExternalProjet_add (
….
SOURCE_DIR c:/sources/my_project
….
BUILD_COMMAND ${MY_CUSTOM_COMMAND} -IN SOURCE_NATIVE_DIR -OUT
BINARY_NATIVE_DIR
…
)
With this approach, the previous behaviour is ensured and it is easy, for
specify cases, to use native paths.
On 26/08/15 09:35, Kislinskiy, Stefan s.kislins...@dkfz-heidelberg.de wrote:
Would you prefer to have a switch for each *_DIR variable for all target
steps, or a common switch but for each target step, like the new USE_TERMINAL
switches in the master?
Von: CHEVRIER, Marc [marc.chevr...@sap.com]
Gesendet: Mittwoch, 26. August 2015 08:49
An: David Cole; Kislinskiy, Stefan
Cc: cmake-developers@cmake.org
Betreff: Re: [cmake-developers] ExternalProject: Use native paths as
substitute for directory tokens
I agree with David.
Offering the possibility to manage native paths in an easy way is a very good
enhancement (Today, I rely on some specific actions when I am on Win32 to
manage native path for ONE specific step of ExternalProject) BUT, offering
only the alternative to have NONE or ALL paths in native form is, by far, too
restrictive.
So I am for the solution providing new patterns as alternative to current ones
to manage native paths, i.e. Adding *_NATIVE_DIR for all already available
*_DIR patterns.
Marc
On 25/08/15 17:31, cmake-developers on behalf of David Cole via
cmake-developers cmake-developers-boun...@cmake.org on behalf of
cmake-developers@cmake.org wrote:
I'm going to let other CMake developers chime in on this one.
It's better than the first patch, because it's opt-in, and you have to
add something to get different than previous behavior, but I'm still
of the opinion that this is very command specific, and you won't
always want all _DIR references as native. In my opinion, it's better
left to the person constructing the ExternalProject_Add call. But I am
curious to hear other CMake devs give their opinions.
David C.
On Tue, Aug 25, 2015 at 3:18 AM, Kislinskiy, Stefan
s.kislins...@dkfz-heidelberg.de wrote:
Dear CMake developers,
any thoughts on the fix? :)
Best regards,
Stefan Kislinskiy
Von: cmake-developers [cmake-developers-boun...@cmake.org] im Auftrag von
Kislinskiy, Stefan [s.kislins...@dkfz-heidelberg.de]
Gesendet: Freitag, 21. August 2015 23:56
An: David Cole; James Johnston
Cc: cmake-developers@cmake.org
Betreff: Re: [cmake-developers] ExternalProject: Use native paths as
substitute for directory tokens
What do you think about the new patch I attached to this mail? It adds an
option NATIVE_DIR_TOKENS to ExternalProjects_Add. I also attached a CMake
script file which tests/shows this feature.
Stefan Kislinskiy
Von: cmake-developers [cmake-developers-boun...@cmake.org] im Auftrag von
David Cole via cmake-developers [cmake-developers@cmake.org]
Gesendet: Donnerstag, 20. August 2015 23:20
An: James Johnston
Cc: cmake-developers@cmake.org
Betreff: Re: [cmake-developers] ExternalProject: Use native paths as
substitute for directory tokens
It's exactly what I am concerned about:
You're asking to change the behavior of something for EVERYONE to
solve a problem which you have encountered. If you change it the way
you have proposed, you will cause problems for others. It has worked
the way it is now since ExternalProject_Add was introduced in CMake
2.8. Changing it unconditionally the way you propose is simply not
feasible for backwards compatibility.
I think commands that take native paths ought NOT to use the *_DIR
replacement values, and instead, ought to pass in variables that
contain the native paths in the first place.
David C.
On Thu, Aug 20, 2015 at 2:58 PM, James Johnston
johnstonj.pub...@codenest.com wrote:
Hi,
Funny you are mailing the list about this, since I just ran into this same
issue today building something totally different from Boost... In this
case it's a build tool that thinks the /U in C:/Users is a new command
line argument, that isn't recognized - and then the subsequent s also
ends up unrecognized... and it all fails... And it has nothing to do with
the working directory, so _Add_Step(WORKING_DIRECTORY) isn't a possible
workaround for me.
Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens
I didn’t even think about switches. I don’t think they are required.
Adding the capability to handle paths in native format seems enough.
Example: I want to use a specific tool for the build step which supports only
native paths
ExternalProjet_add (
….
SOURCE_DIR c:/sources/my_project
….
BUILD_COMMAND ${MY_CUSTOM_COMMAND} -IN SOURCE_NATIVE_DIR -OUT
BINARY_NATIVE_DIR
…
)
With this approach, the previous behaviour is ensured and it is easy, for
specify cases, to use native paths.
On 26/08/15 09:35, Kislinskiy, Stefan s.kislins...@dkfz-heidelberg.de wrote:
Would you prefer to have a switch for each *_DIR variable for all target
steps, or a common switch but for each target step, like the new USE_TERMINAL
switches in the master?
Von: CHEVRIER, Marc [marc.chevr...@sap.com]
Gesendet: Mittwoch, 26. August 2015 08:49
An: David Cole; Kislinskiy, Stefan
Cc: cmake-developers@cmake.org
Betreff: Re: [cmake-developers] ExternalProject: Use native paths as
substitute for directory tokens
I agree with David.
Offering the possibility to manage native paths in an easy way is a very good
enhancement (Today, I rely on some specific actions when I am on Win32 to
manage native path for ONE specific step of ExternalProject) BUT, offering
only the alternative to have NONE or ALL paths in native form is, by far, too
restrictive.
So I am for the solution providing new patterns as alternative to current ones
to manage native paths, i.e. Adding *_NATIVE_DIR for all already available
*_DIR patterns.
Marc
On 25/08/15 17:31, cmake-developers on behalf of David Cole via
cmake-developers cmake-developers-boun...@cmake.org on behalf of
cmake-developers@cmake.org wrote:
I'm going to let other CMake developers chime in on this one.
It's better than the first patch, because it's opt-in, and you have to
add something to get different than previous behavior, but I'm still
of the opinion that this is very command specific, and you won't
always want all _DIR references as native. In my opinion, it's better
left to the person constructing the ExternalProject_Add call. But I am
curious to hear other CMake devs give their opinions.
David C.
On Tue, Aug 25, 2015 at 3:18 AM, Kislinskiy, Stefan
s.kislins...@dkfz-heidelberg.de wrote:
Dear CMake developers,
any thoughts on the fix? :)
Best regards,
Stefan Kislinskiy
Von: cmake-developers [cmake-developers-boun...@cmake.org] im Auftrag von
Kislinskiy, Stefan [s.kislins...@dkfz-heidelberg.de]
Gesendet: Freitag, 21. August 2015 23:56
An: David Cole; James Johnston
Cc: cmake-developers@cmake.org
Betreff: Re: [cmake-developers] ExternalProject: Use native paths as
substitute for directory tokens
What do you think about the new patch I attached to this mail? It adds an
option NATIVE_DIR_TOKENS to ExternalProjects_Add. I also attached a CMake
script file which tests/shows this feature.
Stefan Kislinskiy
Von: cmake-developers [cmake-developers-boun...@cmake.org] im Auftrag von
David Cole via cmake-developers [cmake-developers@cmake.org]
Gesendet: Donnerstag, 20. August 2015 23:20
An: James Johnston
Cc: cmake-developers@cmake.org
Betreff: Re: [cmake-developers] ExternalProject: Use native paths as
substitute for directory tokens
It's exactly what I am concerned about:
You're asking to change the behavior of something for EVERYONE to
solve a problem which you have encountered. If you change it the way
you have proposed, you will cause problems for others. It has worked
the way it is now since ExternalProject_Add was introduced in CMake
2.8. Changing it unconditionally the way you propose is simply not
feasible for backwards compatibility.
I think commands that take native paths ought NOT to use the *_DIR
replacement values, and instead, ought to pass in variables that
contain the native paths in the first place.
David C.
On Thu, Aug 20, 2015 at 2:58 PM, James Johnston
johnstonj.pub...@codenest.com wrote:
Hi,
Funny you are mailing the list about this, since I just ran into this same
issue today building something totally different from Boost... In this
case it's a build tool that thinks the /U in C:/Users is a new command
line argument, that isn't recognized - and then the subsequent s also
ends up unrecognized... and it all fails... And it has nothing to do with
the working directory, so _Add_Step(WORKING_DIRECTORY) isn't a possible
workaround for me.
I think the issue with globally making this change to the existing tokens
is that there could be some external tool/program that is EXPECTING to get
CMake paths, not native paths. Who knows? I am guessing that is what
David Cole was concerned about.
Maybe the right answer is to introduce some NEW tokens while leaving the
behavior of the old ones unchanged. E.g. BINARY_DIR_NATIVE etc. It
would be good
[cmake-developers] [CMake 0015712]: Add support for preprocessor definitions for Microsoft IDL (MIDL) compiler
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15712 == Reported By:Michael Priestman Assigned To: == Project:CMake Issue ID: 15712 Category: CMake Reproducibility:N/A Severity: feature Priority: normal Status: new == Date Submitted: 2015-08-26 07:33 EDT Last Modified: 2015-08-26 07:33 EDT == Summary:Add support for preprocessor definitions for Microsoft IDL (MIDL) compiler Description: There is currently no way (that I can see) of specifying preprocessor definitions to the MIDL. Looking at the Visual Studio 10 generator source code, it never even attempts to write out a PreprocessorDefinitions tag. I would have a go at implementing it myself and submitting a patch, but I'm not sure the best way to go about it. Should you do it via target_compile_definitions using an IDL language tag, then use clOptions.OutputPreprocessorDefinitions(..., IDL)? == Issue History Date ModifiedUsername FieldChange == 2015-08-26 07:33 Michael PriestmanNew 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] nvidia nsight tegra set vcxproj properties (Ant Build) in cmake file
Hi Peter, Note the commit Brad mentioned in another thread: VS: Add more Nsight Tegra generator Android property settings http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8c0afaf4 It adds the ability to set both Native Library Directories and Native Library Dependencies, among other things. Thanks for the link to the forum post, by the way – we forgot to update it and will do that now. -Dmitry From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Peter List Sent: Wednesday, August 26, 2015 5:06 AM To: cmake-developers@cmake.org Subject: [cmake-developers] nvidia nsight tegra set vcxproj properties (Ant Build) in cmake file I have a working hello world cmake + built-in Android using nvidia nsight tegra. It uses SDL2. Unfortunately, after I run cmake I have to manually edit the following in my vcxproj to add SDL2: Configuration Properties Ant Build Native Library Directories, Native Library Dependencies I found this post ( http://bit.ly/1NTgTE3 ) from May 5th (3 months 20 days ago) describing the same issue. Is there an ETA on this? Since this isn't out yet, is there a work-around I can do instead? So far my best idea is to have cmake use add_custom_command() as a post-build step to call a python script that edits the vcxproj file XML. AntBuild AntBuildPath[path]\build-android\android-project/AntBuildPath AndroidManifestLocation[path]\build-android\android-project\AndroidManifest.xml/AndroidManifestLocation NativeLibDirectories../../../SDL2-2.0.3/libs/armeabi-v7a/NativeLibDirectories NativeLibDependenciesSDL2/NativeLibDependencies /AntBuild thank you --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- -- 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] Is there an official FindMKL module?
Hello, I am using the find_package() command to load settings for the Intel Math Kernel Library (MKL). This works through a custom FindMKL.cmake module that I've made for myself. However, when looking at: https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/ I can tell that what I've done is likely only correct for my specific case, and certainly not robust against library version changes and various other changes (openmp, static vs dynamic linking etc.). Instead of a FindMKL.cmake module, an alternative is to have MKL be discovered in the FindBLAS or FindLAPACK modules, but according to what I can find on the bug tracker, that solution is also in a fairly broken state: Bug 14138: http://www.cmake.org/Bug/view.php?id=14138 Bug 13543: http://www.cmake.org/Bug/view.php?id=13543 Bug 13528: http://www.cmake.org/Bug/view.php?id=13528 Google tells me that many people have (like me) created their own FindMKL.cmake module, which are equally specific and tailored. Is anyone aware of a more official FindMKL module available somewhere, or at least something that is being somewhat maintained, either by someone at Kitware or Intel? Or of a plan to develop something like that? kind regards, Siebren Reker -- 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] New policy to address rdynamic
I've implemented a new policy, CMP0065, to restrict the addition of CMAKE_SHARED_LIBRARY_LINK_LANG_FLAGS to executables to only when the ENABLE_EXPORTS target property is set. This should allow us to preserve backwards compatibility in the places it breaks existing binaries but allow us to remove it by default for newer projects. See stage/restrict-shlib-link-flags-to-enable-exports The motivator behind this is to get closer to easily supporting fully static binaries.. Any feedback would be appreciated. - Chuck -- 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] ExternalProject: Use native paths as substitute for directory tokens
-Original Message- From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Kislinskiy, Stefan Sent: Wednesday, August 26, 2015 10:03 To: CHEVRIER, Marc; David Cole Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens I see. Added native-style path replacements for SOURCE_NATIVE_DIR and so on. Also extended the documentation accordingly. Some relatively major/minor/nitpicky thoughts in the interests of thoroughness: * There's no test code. It would be good if there was some code to explicitly test these options for nightly testing. For that matter, I think the original tokens weren't thoroughly tested either (e.g. a quick grep for TMP_DIR doesn't show usage of that token at all in the tests). The whole situation could therefore use some help, I think. There are several existing tests of ExternalProject that could probably be extended to test these tokens as needed. * Token replacement is done for WORKING_DIRECTORY and BYPRODUCTS parameters of add_custom_command. You'd best be sure those parameters of add_custom_command can handle a native path, or else not convert to native paths - even for *_NATIVE tokens - when the path is destined for one of those parameters. (I'd tend to assume the command *could* handle it properly since a lot of users might inadvertently pass them, but it's something that should be double-checked. If the command is passing those paths as-is to the generator, correct operation could even vary by generator.) The easy way out might be to have a parameter on _ep_replace_location_tags declaring whether to ACTUALLY convert native path tokens to native paths, and then callers to that macro can decide if they can / should handle native paths. * It would be useful if the documentation explicitly stated that the old BINARY_DIR friends variables are using CMake paths; currently the documentation does not say - which was a shortcoming of the original docs (as you found out accidentally, it is CMake paths). * Nothing explicitly to do with your patch, but the documentation doesn't state that any of the tokens are valid in ExternalProject_Add; it may be useful to audit the options of ExternalProject_Add and see where they can be used, and document accordingly. (Some are obvious, like CONFIGURE_COMMAND, but some are less obvious, like CMAKE_CACHE_ARGS / CMAKE_CACHE_DEFAULT_ARGS which appear to have their own special handling for these tokens, yet none of that is documented. Even a newcomer might not realize the obvious, if they don't realize that ExternalProject_Add is implemented via ExternalProject_AddStep.) * New features should also be documented in Help/release/dev so that it makes it into the release notes of the next CMake version (i.e. so people notice your new feature). I leave it to others to decide if adding the new *_NATIVE tokens is the right way, or if there's a better way - as I myself am a newcomer to CMake. I think I like it though. :) 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
Re: [cmake-developers] Is there an official FindMKL module?
We sometime struggled to get it working, but we never had to resort to using a FindMKL -- FindBLAS and FindLAPACK work just fine for us, provided we do things correctly. So long as we have sourced the mklvars script that ships with Intel MKL and we put: BLA_VENDOR =Intel10_64lp_seq ccmake /path/to/source/dir Then everything works fine and we have no issues. So we have to give CMake a hint that we want to pick the Intel version rather than the generic one (and we're using the sequential, 64bit MKL -- if you look in FindBLAS you can see other vendor types). Have you had things fail when you setup your environment variables using the scripts Intel provides and when you set the BLA_VENDOR hint as an environment variable? Tim - Original Message - From: Siebren Reker siebren.re...@gmail.com To: cmake-developers@cmake.org Sent: Wednesday, August 26, 2015 10:18:44 AM Subject: [cmake-developers] Is there an official FindMKL module? Hello, I am using the find_package() command to load settings for the Intel Math Kernel Library (MKL). This works through a custom FindMKL.cmake module that I've made for myself. However, when looking at: https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/ I can tell that what I've done is likely only correct for my specific case, and certainly not robust against library version changes and various other changes (openmp, static vs dynamic linking etc.). Instead of a FindMKL.cmake module, an alternative is to have MKL be discovered in the FindBLAS or FindLAPACK modules, but according to what I can find on the bug tracker, that solution is also in a fairly broken state: Bug 14138: http://www.cmake.org/Bug/view.php?id=14138 Bug 13543: http://www.cmake.org/Bug/view.php?id=13543 Bug 13528: http://www.cmake.org/Bug/view.php?id=13528 Google tells me that many people have (like me) created their own FindMKL.cmake module, which are equally specific and tailored. Is anyone aware of a more official FindMKL module available somewhere, or at least something that is being somewhat maintained, either by someone at Kitware or Intel? Or of a plan to develop something like that? kind regards, Siebren Reker -- 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] New policy to address rdynamic
Maybe [TARGET_PROPERTIES prop1 value1 [prop1 value1]... ] makes sense instead? That would allow setting ANDROID_API, WIN32_EXECUTABLE etc. Good idea! I actually do like that better, but it's outside the scope of this change. For now I'll remove the ENABLE_EXPORTS but still propagate the policy and then push a separate branch to add the TARGET_PROPERTIES argument. Thanks - Chuck -- 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] Add a test for checking that the CPack module produces correct config files
Domen Vrankar domen.vran...@gmail.com писал в своём письме Wed, 26 Aug 2015 22:27:43 +0300: 2015-08-19 21:08 GMT+02:00 Роман Донченко d...@corrigendum.ru: Currently, the only case is for simple variable values (not containing any CMake-special characters and not determined by CPack itself). In CPackRPM and CPackDeb both cases that this is testing (CMake list variable and a variable containing spaces) are already tested implicitly. RunCMake.CPack contains such test. Admittedly both cases are not present in same variable. Is this test targeting a particular CPack generator or a CMake-CPack bug on a particular OS? My motivation is this. I want to submit a few improvements to the way CPack writes config files, starting with that cpack_set_if_not_set change I mentioned a while back. This functionality is generator-independent (and basically unrelated to actual package generation), so I thought RunCMake.CPack was not the appropriate place to test it. Since there doesn't seem to be a test suite specifically for config file writing, I thought I'd create one in a separate patch so that my later patches don't have as much boilerplate in them. The Simple test is just there to ensure I don't break the simple case while changing the more complex ones. Well, and it would be silly to submit a test suite with no tests in it. Roman. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
