Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive
Le 15/09/15 08:43, Domen Vrankar a écrit : 2015-09-14 23:49 GMT+02:00 Raffi Enficiaud: Le 14/09/15 23:34, Domen Vrankar a écrit : Thank you. However those two test are not mutually exclusive. I think having them on lintian is also a good thing. I've tried your test change before but lintian test complained that 775 are invalid permissions (should be 755). Is this caused by a different version of lintian or should I just modify your test to use 755 permissions and apply that? That's very good that it fails :) I tested on Ubuntu 14.04, maybe Debian distributions are even more strict. Apparently the files that "file(WRITE ...)" created on your system are with 775. I believe the problem lies in the "file(" commands rather than on a different version of lintian. OTOH, I can see from this: https://lintian.debian.org/tags/control-file-has-bad-permissions.html that all files should have at least a permission mask set to ~S_IWGRP & ~S_IWOTH (with "control_tar.SetPermissionsMask(~S_IWGRP & ~S_IWOTH)"), so that the executable bit is left unchanged and the write bit is cleared for group and others (755 and 644). What do you think? You are correct. I've reinstalled my virtual machine and retested with "control_tar.SetPermissionsMask(~S_IWGRP & ~S_IWOTH)" and it would seem that there was an issue in my testing environment - before this did not work as expected on my machine. Same goes for default permissions being 664/775 instead of 644/755. I would keep md5 checksum file permissions on 644 with SetPermissions and add SetPermissionsMask from above for the rest of control files. Would you agree? From this (thanks to lintian now I have the proper link :) ) https://lintian.debian.org/tags/control-file-has-bad-permissions.html https://www.debian.org/doc/debian-policy/ch-files.html#s-permissions-owners all control files: - should be owned by root:root (+ I would say uid/gid 0/0, because root may be mapped) which is the case now - should be 755 or 644, depending if they are executable or not The number of files that should be 755 are limited to (according to linitian) config, postinst, postrm, preinst, and prerm. All others should be 644. So I would say without loss of generality, we can set the permission to 644 except for those config, postinst... files . I can send you a patch based on 76c59007dd3944e23848b7d5912a59a7d3db6398 today (and update the doc accordingly). Is that good for you? 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] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive
2015-09-14 23:49 GMT+02:00 Raffi Enficiaud: > Le 14/09/15 23:34, Domen Vrankar a écrit : >>> >>> Thank you. However those two test are not mutually exclusive. I think >>> having >>> them on lintian is also a good thing. >> >> >> I've tried your test change before but lintian test complained that >> 775 are invalid permissions (should be 755). Is this caused by a >> different version of lintian or should I just modify your test to use >> 755 permissions and apply that? >> > > That's very good that it fails :) > > I tested on Ubuntu 14.04, maybe Debian distributions are even more strict. > Apparently the files that "file(WRITE ...)" created on your system are with > 775. I believe the problem lies in the "file(" commands rather than on a > different version of lintian. > > OTOH, I can see from this: > > https://lintian.debian.org/tags/control-file-has-bad-permissions.html > > that all files should have at least a permission mask set to ~S_IWGRP & > ~S_IWOTH (with "control_tar.SetPermissionsMask(~S_IWGRP & ~S_IWOTH)"), so > that the executable bit is left unchanged and the write bit is cleared for > group and others (755 and 644). > > What do you think? You are correct. I've reinstalled my virtual machine and retested with "control_tar.SetPermissionsMask(~S_IWGRP & ~S_IWOTH)" and it would seem that there was an issue in my testing environment - before this did not work as expected on my machine. Same goes for default permissions being 664/775 instead of 644/755. I would keep md5 checksum file permissions on 644 with SetPermissions and add SetPermissionsMask from above for the rest of control files. Would you agree? Thanks, 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
[cmake-developers] [CPack][BUG] Fail to package with CPACK_INSTALLED_DIRECTORIES
Hi, To enable to handle various packages as part of the same project and to avoid to execute preinstall target before packaging, I rely on CPack variables CPACK_INSTALLED_DIRECTORIES and CPACK_INSTALL_COMMANDS. Unfortunately, packaging is failing in the following conditions: * Platform Windows (regardless generator: test done with “Visual Studio” and "Ninja”) * Install command with PERMISSIONS read-only (like OWNER_READ) * PROJECT command with LANGUAGES CXX (specifying LANGUAGES NONE is OK !??) In this case, installed read-only files cannot be copied by CPack. Attached is a CMakeLists.txt showing the problem: * Target package-OK generates the expected package (no read-only permissions) * Target package-KO fails to generate the package (same as previous one except read-only permissions) Marc cmake_minimum_required (VERSION 3.1) project (TEST LANGUAGES CXX) install (FILES file.h PERMISSIONS OWNER_READ GROUP_READ WORLD_READ DESTINATION include COMPONENT KO) install (FILES file.h DESTINATION include COMPONENT OK) set (CPACK_GENERATOR "TGZ") set (install_prefix ${CMAKE_SOURCE_DIR}/INSTALL) set (KO_install_command "${CMAKE_COMMAND} -DCMAKE_INSTALL_PREFIX=${install_prefix} -DCOMPONENT=KO -DBUILD_TYPE=$ -P ${CMAKE_BINARY_DIR}/cmake_install.cmake") add_custom_target (package-KO COMMAND "${CMAKE_CPACK_COMMAND}" -C $ -D CPACK_COMPONENTS_ALL=KO -D CPACK_INSTALL_COMMANDS=${KO_install_command} -D CPACK_INSTALLED_DIRECTORIES=${install_prefix}$. --config ./CPackConfig.cmake) set (OK_install_command "${CMAKE_COMMAND} -DCMAKE_INSTALL_PREFIX=${install_prefix} -DCOMPONENT=OK -DBUILD_TYPE=$ -P ${CMAKE_BINARY_DIR}/cmake_install.cmake") add_custom_target (package-OK COMMAND "${CMAKE_CPACK_COMMAND}" -C $ -D CPACK_COMPONENTS_ALL=OK -D CPACK_INSTALL_COMMANDS=${OK_install_command} -D CPACK_INSTALLED_DIRECTORIES=${install_prefix}$. --config ./CPackConfig.cmake) include (CPack) -- 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] Allow ALIAS of IMPORTED targets
I completely agree. Seems reasonable to disallow exporting ALIAS targets. Marc On 14/09/15 19:34, "cmake-developers on behalf of Stephen Kelly"wrote: >Michael Scott wrote: > >> Hi, >> >> I'm planning on having a look at the CMake issue "Allow ALIAS of >> IMPORTED targets", 0015569. After reading the thread between yourself >> and Marc, I wanted to ask a couple of things before I start going >> further with it. > >Thanks for working on this. > >> The proposed change would be for the add_library and add_executable >> commands only right? > >Yes, I guess so. > >> Having a quick look at the code for those two commands, they >> specifically check for a combination of ALIAS and IMPORTED and don't >> allow it. I'm guessing that the required changes to allow both >> simultaneously wouldn't be to just remove this check, there would be >> other areas to modify as well right? > >Perhaps. Finding that out is the real task :). I don't have all the answers >to it. The specific disallowing of ALIAS and IMPORTED together by issuing an >error was a way to defer finding those answers while not being required to >maintain compatibility with a particular behavior. I didn't want finding >those answers to delay getting the ALIAS feature in, because it was useful >already as it was. > >Now, we have time to consider all of the implications of allowing this as >part of the design. > >For example, if an ALIAS can be IMPORTED, does it makes sense that it can be >exported with export() and install(EXPORT)? > >If we have > > add_library(CoreStatic ${Core_SRCS}) > add_library(MyNS::Core ALIAS CoreStatic) > >and I export both of them with the NAMESPACE 'MyNS::', do I end up with > > MyNS::MyNS::Core > >? > >Or would the exporting code strip of everything before a '::' in the alias >name? > >Or should exporting ALIAS targets still be disallowed? > >The two use cases described in > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/52452 > >seem like they would not benefit from exporting ALIAS targets. > >A reasonable way forward might be: > >* Keep the restriction that ALIAS targets may not be exported. >* Remove the code disallowing ALIAS IMPORTED targets. >* Remove the unit test proving it is not allowed >* Add new unit tests that it basically works >* Add a unit test for using an ALIAS with try_compile(LINK_LIBRARIES) >* (Anything else that comes up along the way) > >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 -- 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 0015745]: Export target with multiple names
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15745 == Reported By:Stephen Kelly Assigned To: == Project:CMake Issue ID: 15745 Category: CMake Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2015-09-15 19:36 CEST Last Modified: 2015-09-15 19:36 CEST == Summary:Export target with multiple names Description: As discussed in == Issue History Date ModifiedUsername FieldChange == 2015-09-15 19:36 Stephen Kelly 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] Allow ALIAS of IMPORTED targets
Tamás Kenéz wrote: >> For example, if an ALIAS can be IMPORTED, does it makes sense that it can > be >> exported with export() and install(EXPORT)? > > Yes: couple of months ago I was adding install(EXPORT) to an existing > CMakeList. The name of the library target which I had to export was not > correct as export target name but I was not able change the library target > name because of backward compatibility. Being able to export an alias > would have helped. I still think exporting should be a follow up to allowing IMPORTED ALIAS. Just too keep the branch and discussion as short as possible. Nevertheless, I think you wouldn't need ALIAS targets for your use-case. They are more than you need. You don't need the aliases anywhere except for exporting. So, we could design something which allows you to export aliases, but be completely separate from ALIAS targets. For example, add_library(foo ${foo_SRCS}) set_target_property(foo EXPORT_NAMES foo foo_old_name) ... install(EXPORT ...) resulting in a generated file containing add_library(foo IMPORTED) ... add_library(foo_old_name IMPORTED) ... where each of the generated targets get the same target properties. Note that there is already an EXPORT_NAME target property http://www.cmake.org/cmake/help/v3.3/prop_tgt/EXPORT_NAME.html but it is not a list, so the task would probably be to deprecate that one and add EXPORT_NAMES. I filed http://public.kitware.com/Bug/view.php?id=15745 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] xcode7-defaults-to-c11 topic
Hi Gregor, Thanks for working on this topic. As GNU 6 defaults to C++14, and clang will probably follow suit, I think it is better to determine the default dialect automatically instead of maintaining numbers like that in Modules/. I have merged a Konsole output compute-default-dialect to next for testing which implements the automatic detection. Please test it to see if it works with xcode 7. 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
Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive
> From this (thanks to lintian now I have the proper link :) ) > > https://lintian.debian.org/tags/control-file-has-bad-permissions.html > https://www.debian.org/doc/debian-policy/ch-files.html#s-permissions-owners > > all control files: > - should be owned by root:root (+ I would say uid/gid 0/0, because root may > be mapped) which is the case now > - should be 755 or 644, depending if they are executable or not > > The number of files that should be 755 are limited to (according to > linitian) config, postinst, postrm, preinst, and prerm. All others should be > 644. > > So I would say without loss of generality, we can set the permission to 644 > except for those config, postinst... files . I can send you a patch based on > 76c59007dd3944e23848b7d5912a59a7d3db6398 today (and update the doc > accordingly). > > Is that good for you? Sounds good. Those rules are written as guidelines and I'm not certain how often they are broken so could you also add a single variable for toggling between defaults described above and using file permissions as provided? Thanks, 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] Python extension to FindProtobuf
Sorry, found a stashed change, that I missed. With that it works. -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Montag, 14. September 2015 16:12 To: Andreas Bergmeier Cc: Rolf Eike Beer; cmake-developers@cmake.org Subject: Re: [cmake-developers] Python extension to FindProtobuf On 09/14/2015 03:42 AM, Andreas Bergmeier wrote: > I now added documentation, removed ARGS and GENERATED property. Thanks. Applied with minor wording tweaks: FindProtobuf: Add protobuf_generate_python function http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=143579c3 -Brad Diese E-mail enthält VERTRAULICHE UND PERSÖNLICHE INFORMATIONEN und/oder PRIVILEGIERTE UND VERTRAULICHE MITTEILUNGEN, die ausschließlich für die angesprochenen Empfänger bestimmt sind. Ohne ausdrückliche schriftliche Zustimmung des Absenders dürfen diese Informationen und Mitteilungen nicht an irgendeinen Dritten außerhalb der Organisation des Empfängers weitergeleitet oder zur Kenntnis gebracht werden. Wenn Sie diese E-mail versehentlich empfangen haben, teilen Sie dies bitte dem Absender umgehend telefonisch oder durch Rücksendung dieser E-mail mit, und zerstören Sie die Mail sowie Ihre evtl. Rückmail bitte anschließend, ohne eine Kopie zu erstellen. Koch Media übernimmt keinerlei Verantwortung für mögliche Verluste oder Beschädigungen, resultierend aus virus-infizierten E-mails bzw. Viren in Anhängen. This e-mail may contain CONFIDENTIAL AND PROPRIETARY INFORMATION and/or PRIVILEGED AND CONFIDENTIAL COMMUNICATION intended solely for the recipient and, therefore, may not be retransmitted to any party outside of the recipient's organization without the prior written consent of the sender. If you have received this e-mail in error please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Koch Media accepts no liability for any losses or damages resulting from infected e-mail transmissions and viruses in e-mail attachment. commit-ddb5ae6 Description: commit-ddb5ae6 -- 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 user-provided manifest files
> -Original Message- > From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] > On Behalf Of Brad King > Sent: Monday, September 14, 2015 20:16 > To: James Johnston > Cc: cmake-developers@cmake.org > Subject: Re: [cmake-developers] CMake user-provided manifest files > > On 09/11/2015 11:45 AM, James Johnston wrote: > > Because CMake already does *some* things with the linker it makes it > > impossible for me to cleanly specify and use link.exe manifest-related > > switches myself. For example, it hard-codes usage of link.exe > > /MANIFESTFILE and the user can't specify their own location. And the > > locations it does use are undocumented. > > Is there a use case for doing something with the linker-generated manifest > file other than passing it to a "mt" invocation along with (possibly) user- > specified manifest files? If not then there is no reason to make the manifest > file location public. I can't think of anything like that. The only reason I was using the undocumented linker-generated manifest location was to merge it with my own manifest using mt.exe. So I agree, I can't think of a reason the location needs to be publicly documented/available if CMake can cleanly handle user-provided manifests to merge. 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] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive
Le 15/09/15 11:00, Domen Vrankar a écrit : Sounds good. Those rules are written as guidelines and I'm not certain how often they are broken so could you also add a single variable for toggling between defaults described above and using file permissions as provided? I think those are not really just "guidelines" if you want ever your source package be published with a cmake toolchain (severity "serious"). Please find attached the "feature" based onto 68dba7f. I added the variable CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION and its component counterpart for controlling strict behaviour on the files added to control.tar.gz . I added a test over lintian again, as I think lintian is the official tool for checking those things. Please note that I was not able to check the produced documentation (although I updated it). I would be happy if you can do it, otherwise I will do tonight. Thanks! Raffi PS.: what about the other patches? >From 36f273c1e07651060deaea3b576150151ed65818 Mon Sep 17 00:00:00 2001 From: Raffi EnficiaudDate: Tue, 15 Sep 2015 11:26:53 +0200 Subject: [PATCH] fixUp! permissions on control files and strict Debian rules variable --- Modules/CPackDeb.cmake | 30 ++--- Source/CPack/cmCPackDebGenerator.cxx| 39 ++--- Tests/CPackComponentsDEB/CMakeLists.txt | 19 3 files changed, 82 insertions(+), 6 deletions(-) diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake index 754df91..43b49f8 100644 --- a/Modules/CPackDeb.cmake +++ b/Modules/CPackDeb.cmake @@ -330,9 +330,30 @@ # .. note:: # #The original permissions of the files will be used in the final -#package. In particular, the scripts should have the proper executable +#package unless the variable +#:variable:`CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION` is set. +#In particular, the scripts should have the proper executable #flag prior to the generation of the package. - +# +# .. variable:: CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION +# CPACK_DEBIAN__PACKAGE_CONTROL_STRICT_PERMISSION +# +# This variable indicates if the Debian policy on control files should be +# strictly followed. +# +# * Mandatory : NO +# * Default : FALSE +# +# Usage:: +# +# set(CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION TRUE) +# +# .. note:: +# +#This overrides the permissions on the original files, following the rules +#set by Debian policy +# https://www.debian.org/doc/debian-policy/ch-files.html#s-permissions-owners +# #= # Copyright 2007-2009 Kitware, Inc. @@ -636,7 +657,7 @@ function(cpack_deb_prepare_package_vars) # Are we packaging components ? if(CPACK_DEB_PACKAGE_COMPONENT) # override values with per component version if set -foreach(VAR_NAME_ "PACKAGE_CONTROL_EXTRA") +foreach(VAR_NAME_ "PACKAGE_CONTROL_EXTRA" "PACKAGE_CONTROL_STRICT_PERMISSION") if(CPACK_DEBIAN_${_local_component_name}_${VAR_NAME_}) set(CPACK_DEBIAN_${VAR_NAME_} "${CPACK_DEBIAN_${_local_component_name}_${VAR_NAME_}}") endif() @@ -658,6 +679,7 @@ function(cpack_deb_prepare_package_vars) message("CPackDeb:Debug: CPACK_PACKAGE_FILE_NAME = ${CPACK_PACKAGE_FILE_NAME}") message("CPackDeb:Debug: CPACK_PACKAGE_INSTALL_DIRECTORY = ${CPACK_PACKAGE_INSTALL_DIRECTORY}") message("CPackDeb:Debug: CPACK_TEMPORARY_PACKAGE_FILE_NAME = ${CPACK_TEMPORARY_PACKAGE_FILE_NAME}") + message("CPackDeb:Debug: CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION = ${CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION}") endif() # For debian source packages: @@ -694,6 +716,8 @@ function(cpack_deb_prepare_package_vars) set(GEN_CPACK_DEBIAN_PACKAGE_PROVIDES "${CPACK_DEBIAN_PACKAGE_PROVIDES}" PARENT_SCOPE) set(GEN_CPACK_DEBIAN_PACKAGE_REPLACES "${CPACK_DEBIAN_PACKAGE_REPLACES}" PARENT_SCOPE) set(GEN_CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA "${CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA}" PARENT_SCOPE) + set(GEN_CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION + "${CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION}" PARENT_SCOPE) set(GEN_WDIR "${WDIR}" PARENT_SCOPE) endfunction() diff --git a/Source/CPack/cmCPackDebGenerator.cxx b/Source/CPack/cmCPackDebGenerator.cxx index 981d86d..b497b65 100644 --- a/Source/CPack/cmCPackDebGenerator.cxx +++ b/Source/CPack/cmCPackDebGenerator.cxx @@ -576,9 +576,18 @@ int cmCPackDebGenerator::createDeb() control_tar.SetUNAME("root"); control_tar.SetGNAME("root"); -// set md5sum file permissions to RW-R--R-- so that deb lintian -// doesn't warn about it -control_tar.SetPermissions(S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH); +// permissions are set according to +// https://www.debian.org/doc/debian-policy/ch-files.html#s-permissions-owners +// and +//
[cmake-developers] [CMake 0015743]: get_filename_component turns real path to ABSOLUTE path
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15743 == Reported By:Andreas Schuh Assigned To: == Project:CMake Issue ID: 15743 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-09-15 11:15 EDT Last Modified: 2015-09-15 11:15 EDT == Summary:get_filename_component turns real path to ABSOLUTE path Description: I encountered a very strange behaviour of the get_filename_component using the ABSOLUTE subcommand. The given input path was before turned into a real path with symbolic links resolved using the REALPATH subcommand. Calling get_filename_component with ABSOLUTE on this real path I would have expected an unchanged path. Instead, ABSOLUTE returns a path with symbolic links again! Note that both the source and build directory are located in different symlinked directory paths. Looking at the C++ code of the get_filename_component command revealed some strange call to SystemTools::CheckTranslationPath in SystemTools::CollapseFullPath which implements the ABSOLUTE subcommand. There is also a commented line beforehand with a comment expecting to break something by doing so... the call to SystemTools::AddTranslationPath. The issue affects also previous releases (tried 3.2.2 and 2.8.12.2). IMHO I find it extremely strange that get_filename_component needs such translation table (without having digged deeper to fully understand its purpose). Cleaning a path or splitting it into parts should be a purely string based operation without actual file system information. Steps to Reproduce: 1. Create directory hierarchy with symlinks similar to my scenario: Real source directory: /vol/medic01/users/as12312/Code/CMakeGetFileNameComponentIssue Real build directory: /vol/biomedic/users/as12312/build/merapi/cmake-get_filename_component-issue Symbolic links: /homes/as12312/Code -> /vol/medic01/users/as12312/Code /homes/as12312/opt -> /vol/biomedic/users/as12312 2. Copy attached CMakeLists.txt to the source directory 3. Change into the symlinked build directory and use the symbolic link to the source directory as argument to CMake cd /homes/as12312/opt/build/merapi/cmake-get_filename_component-issue cmake /homes/as12321/Code/CMakeGetFileNameComponentIssue The output is the following: CMAKE_SOURCE_DIR: REALPATH = /vol/medic01/users/as12312/Code/CMakeGetFileNameComponentIssue ABSOLUTE = /vol/medic01/users/as12312/Code/CMakeGetFileNameComponentIssue CMAKE_BINARY_DIR: REALPATH = /vol/biomedic/users/as12312/build/merapi/cmake-get_filename_component-issue ABSOLUTE = /homes/as12312/opt/build/merapi/cmake-get_filename_component-issue -- Configuring done -- Generating done -- Build files have been written to: /homes/as12312/opt/build/merapi/cmake-get_filename_component-issue Note that the ABSOLUTE return value of get_filename_component of the real input path contains symbolic links again! == Issue History Date ModifiedUsername FieldChange == 2015-09-15 11:15 Andreas Schuh New Issue 2015-09-15 11:15 Andreas Schuh File Added: CMakeLists.txt == -- 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 0015744]: Spaces in paths with non-ASCII characters are not escaped when using Ninja
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15744 == Reported By:Thiago M. Assigned To: == Project:CMake Issue ID: 15744 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2015-09-15 13:21 EDT Last Modified: 2015-09-15 13:21 EDT == Summary:Spaces in paths with non-ASCII characters are not escaped when using Ninja Description: When using CMake with the Ninja generator to build some source code that is inside a path that contains both spaces and non-ASCII characters, the path is used without escaping the spaces inside the generated Ninja rules files. Steps to Reproduce: 1) Create a sources folder in a path which contains both spaces and non-ASCII characters. Ex: `make /tmp/CMake Ninja Spaces/Código` 2) Inside the source folder, create a `CMakeLists.txt` with an `add_executable(main main.cpp)`. 3) Run CMake using the Ninja generator. 4) Check the generated `build.ninja` file. It should have spaces in paths escaped with `$`, like: build CMakeFiles/CMakeNinjaSpaces.dir/main.cpp.o: CXX_COMPILER__CMakeNinjaSpaces /tmp/CMake$ Ninja$ Spaces/Código/main.cpp However, it has variables names `identX` with unescaped paths: ident0 = /tmp/CMake Ninja Spaces/Código/main.cpp build CMakeFiles/CMakeNinjaSpaces.dir/main.cpp.o: CXX_COMPILER__CMakeNinjaSpaces $ident0 Additional Information: The unescaped paths make Ninja rebuild and relink everything whenever it runs, making incremental builds and the edit-build-test cicle impossible. Steps to reproduce (cont.): 5) Run Ninja on the generated `build.ninja` file. It outputs the progress of files being build: [1/2] Building CXX object CMakeFiles/CMakeNinjaSpaces.dir/main.cpp.o [2/2] Linking CXX executable CMakeNinjaSpaces 6) Run Ninja again. It should do nothing and print: `ninja: no work to do.` However, it does rebuild and relink everything, showing again the progress messages described in step 5. == Issue History Date ModifiedUsername FieldChange == 2015-09-15 13:21 Thiago M. New Issue 2015-09-15 13:21 Thiago M. File Added: build.ninja == -- 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 0015746]: pkg_check_modules should document how to handle spaces in framework names
The following issue has been SUBMITTED. == https://public.kitware.com/Bug/view.php?id=15746 == Reported By:Dan Kegel Assigned To: == Project:CMake Issue ID: 15746 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-09-15 15:20 EDT Last Modified: 2015-09-15 15:20 EDT == Summary:pkg_check_modules should document how to handle spaces in framework names Description: pc files don't often have spaces in values, but it does happen (especially on the Mac), and a little guidance would be helpful. http://kegel.com/cmake/spaces-in-framework-names/ is a worked example of how to cope with framework names that contain spaces. The idea is: - the .pc file should use a backslash in front of each space in the name (quotes don't seem to work) - the CMakeLists.txt should use string(REPLACE...) to replace semicolons with spaces and/or single quote marks, as appropriate For instance: string(REPLACE "-framework;foo;bar" "-framework 'foo bar'" foo_LDFLAGS "${foo_LDFLAGS}") Steps to Reproduce: On a mac: $ tar -xzvf spaces-in-framework-names.tgz $ cd spaces-in-framework-names # comment out the string(REPLACE...) in CMakeLists.txt to demonstrate problem $ sh demo.sh == Issue History Date ModifiedUsername FieldChange == 2015-09-15 15:20 Dan Kegel New Issue 2015-09-15 15:20 Dan Kegel File Added: spaces-in-framework-names.tgz == -- 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] Do not build CMake in C11 mode if _Thread_local support is broken.
On 09/15/2015 10:31 AM, Raphael Kubo da Costa wrote: > Add a test for _Thread_local support and only build CMake itself with > C11 support if it works. > > Bug: http://www.cmake.org/Bug/view.php?id=15741 Thanks, applied: Avoid using C11 to build CMake if _Thread_local support is broken http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ffa6f057 -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] Allow ALIAS of IMPORTED targets
Thank you, I was not aware of the EXPORT_NAME target property. Tamas On Tue, Sep 15, 2015 at 7:36 PM, Stephen Kellywrote: > Tamás Kenéz wrote: > > >> For example, if an ALIAS can be IMPORTED, does it makes sense that it > can > > be > >> exported with export() and install(EXPORT)? > > > > Yes: couple of months ago I was adding install(EXPORT) to an existing > > CMakeList. The name of the library target which I had to export was not > > correct as export target name but I was not able change the library > target > > name because of backward compatibility. Being able to export an alias > > would have helped. > > I still think exporting should be a follow up to allowing IMPORTED ALIAS. > Just too keep the branch and discussion as short as possible. > > Nevertheless, I think you wouldn't need ALIAS targets for your use-case. > They are more than you need. You don't need the aliases anywhere except for > exporting. So, we could design something which allows you to export > aliases, > but be completely separate from ALIAS targets. > > For example, > > add_library(foo ${foo_SRCS}) > set_target_property(foo EXPORT_NAMES foo foo_old_name) > > ... > > install(EXPORT ...) > > resulting in a generated file containing > > add_library(foo IMPORTED) > ... > > add_library(foo_old_name IMPORTED) > ... > > where each of the generated targets get the same target properties. > > Note that there is already an EXPORT_NAME target property > > http://www.cmake.org/cmake/help/v3.3/prop_tgt/EXPORT_NAME.html > > but it is not a list, so the task would probably be to deprecate that one > and add EXPORT_NAMES. > > I filed > > http://public.kitware.com/Bug/view.php?id=15745 > > 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 > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] Do not build CMake in C11 mode if _Thread_local support is broken.
Support for C11's _Thread_local was introduced in GCC in the 4.9 series, even though we make the C11 compiler flags available in CMake with GCC >= 4.6. FreeBSD's runetype.h uses _Thread_local, which causes CMake's own build to fail when using GCC < 4.9 and -std=gnu11: /usr/include/runetype.h:92:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'const' extern _Thread_local const _RuneLocale *_ThreadRuneLocale; Add a test for _Thread_local support and only build CMake itself with C11 support if it works. Bug: http://www.cmake.org/Bug/view.php?id=15741 --- CMakeLists.txt | 7 ++- Source/Checks/cm_c11_thread_local.c | 2 ++ Source/Checks/cm_c11_thread_local.cmake | 33 + 3 files changed, 41 insertions(+), 1 deletion(-) create mode 100644 Source/Checks/cm_c11_thread_local.c create mode 100644 Source/Checks/cm_c11_thread_local.cmake diff --git a/CMakeLists.txt b/CMakeLists.txt index 5e13a7e..94d138c 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -38,7 +38,12 @@ endif() # Use most-recent available language dialects with GNU and Clang if(NOT DEFINED CMAKE_C_STANDARD AND NOT CMake_NO_C_STANDARD) - set(CMAKE_C_STANDARD 11) + include(${CMake_SOURCE_DIR}/Source/Checks/cm_c11_thread_local.cmake) + if(NOT CMake_C11_THREAD_LOCAL_BROKEN) +set(CMAKE_C_STANDARD 11) + else() +set(CMAKE_C_STANDARD 99) + endif() endif() if(NOT DEFINED CMAKE_CXX_STANDARD AND NOT CMake_NO_CXX_STANDARD) include(${CMake_SOURCE_DIR}/Source/Checks/cm_cxx14_cstdio.cmake) diff --git a/Source/Checks/cm_c11_thread_local.c b/Source/Checks/cm_c11_thread_local.c new file mode 100644 index 000..ab780f2 --- /dev/null +++ b/Source/Checks/cm_c11_thread_local.c @@ -0,0 +1,2 @@ +_Thread_local int i = 42; +int main(void) { return 0; } diff --git a/Source/Checks/cm_c11_thread_local.cmake b/Source/Checks/cm_c11_thread_local.cmake new file mode 100644 index 000..6b8d10b --- /dev/null +++ b/Source/Checks/cm_c11_thread_local.cmake @@ -0,0 +1,33 @@ +set(CMake_C11_THREAD_LOCAL_BROKEN 0) +if(CMAKE_CXX_COMPILER_ID MATCHES "GNU" AND CMAKE_C11_STANDARD_COMPILE_OPTION) + if(NOT DEFINED CMake_C11_THREAD_LOCAL_WORKS) +message(STATUS "Checking if compiler supports C11 _Thread_local") +try_compile(CMake_C11_THREAD_LOCAL_WORKS + ${CMAKE_CURRENT_BINARY_DIR} + ${CMAKE_CURRENT_LIST_DIR}/cm_c11_thread_local.c + CMAKE_FLAGS -DCMAKE_C_STANDARD=11 + OUTPUT_VARIABLE OUTPUT + ) +if(CMake_C11_THREAD_LOCAL_WORKS AND "${OUTPUT}" MATCHES "error: expected '=', ',', ';', 'asm' or '__attribute__' before 'int'") + set_property(CACHE CMake_C11_THREAD_LOCAL_WORKS PROPERTY VALUE 0) +endif() +if(CMake_C11_THREAD_LOCAL_WORKS) + message(STATUS "Checking if compiler supports C11 _Thread_local - yes") + file(APPEND ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeOutput.log +"Determining if compiler supports C11 _Thread_local passed with the following output:\n" +"${OUTPUT}\n" +"\n" +) +else() + message(STATUS "Checking if compiler supports C11 _Thread_local - no") + file(APPEND ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeError.log +"Determining if compiler supports C11 _Thread_local failed with the following output:\n" +"${OUTPUT}\n" +"\n" +) +endif() + endif() + if(NOT CMake_C11_THREAD_LOCAL_WORKS) +set(CMake_C11_THREAD_LOCAL_BROKEN 1) + endif() +endif() -- 2.5.2 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks
Hi All, I've attached three suggested patches for cmake. The first is trivial, it simply adds Python 3.5 and 3.6 to the search list. The second removes the long-deprecated PYTHON_INCLUDE_PATH as a suggestion for PYTHON_INCLUDE_DIR. The third does two important things: 1) it fixes bugs for searching for specific versions of the libs and headers for framework installs of Python on OS X, and 2) it doesn't search for the include directory until after library has been found, so that it can use the library version to direct the search for the include directory. Any comments on these patches would be appreciated. Cheers, - David 0001-Add-Python-3.6-3.5-to-the-versions-searched-for.patch Description: Binary data 0002-Remove-PYTHON_INCLUDE_PATH-as-input-to-FindPythonLib.patch Description: Binary data 0003-Match-python-include-dir-to-library-version.patch Description: Binary data -- 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