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

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

[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

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

[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:

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

[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

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,

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

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

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

[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:

[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:

[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:

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

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 Kelly wrote: > 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

[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:

[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