[cmake-developers] [CPackDeb] use of internal md5sum function

Hi Brad and Domen and others, Please find attached a patch on CPackDeb - which calls the internal function for md5sum computation - which prevents the hash of the symlinks I believe this fixes the issue (partially or totally) https://public.kitware.com/Bug/view.php?id=13386 It is based on my

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

Le 14/09/15 11:51, Raffi Enficiaud a écrit : Hi Brad and Domen and others, I just realized that the permissions for the extra control files should be set in a different way than for the md5sum checksum file. Please find attached the patch correcting this and the corresponding test that fires

[cmake-developers] [CMake 0015742]: string(REGEX MATCH) and string(REGEX MATCHALL) concatenate arguments

The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15742 == Reported By:Fujii Hironori Assigned To:

[cmake-developers] [CPackDeb] empty directories in packages

Hi Brad and Domen and others, I was looking at this issue http://public.kitware.com/Bug/view.php?id=13009 and apparently it is not possible to install empty directories (I just tested). I believe that it should be possible to do that (even if there are better ways like postinst). What is

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 -- Powered by

Re: [cmake-developers] Portability patches / bug fixes

On 09/12/2015 11:03 AM, Joerg Sonnenberger wrote: > attached are three patches for cmake. The first two should be trivial > and self-explaining. The third is a more involved change for ccmake. Thanks. I've applied the changes: jsoncpp: Fix compilation as C99 on Solaris

Re: [cmake-developers] find_program HINTS no longer preferred over PATH

On 09/14/2015 03:05 AM, CHEVRIER, Marc wrote: > Any news on this subject? Chuck has had a fix in 'next' for a few days: find_*: Fix search order when the environment duplicates some HINTS http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ec8e5fb3 but the topic is still missing a test case.

Re: [cmake-developers] Listing all targets

Finally getting back to this, hopefully can push to next this week, and have this completed in time for the upcoming 3.4 release. I have three questions before attempting my first merge-to-next for testing: (1) I see how I can easily move "COMPONENTS" from cmGetCMakePropertyCommand::InitialPass

[cmake-developers] [PATCH] Features: Only enable C11 support on GCC >= 4.9.

As of version 3.3.1, CMake sets CMAKE_C11_STANDARD_COMPILE_OPTION and CMAKE_C11_EXTENSION_COMPILE_OPTION for GCC >= 4.7, and checks for C11 features for GCC >= 4.6. It also means CMake itself will be built with -std=gnu11 if GCC >= 4.7 is used. However, GCC only has full C11 support with the 4.9

Re: [cmake-developers] [PATCH] Features: Only enable C11 support on GCC >= 4.9.

Raphael Kubo da Costa wrote: > Adjust the GCC feature detection code to only consider C11 support to > exist on GCC >= 4.9. If you do that you must remove the definition of CMAKE_CXX11_STANDARD_COMPILE_OPTION for GNU < 4.8.1 too. IOW, this patch is not correct, and should not be merged.

Re: [cmake-developers] Listing all targets

On 09/14/2015 11:46 AM, David Cole wrote: > (1) I see how I can easily move "COMPONENTS" from > cmGetCMakePropertyCommand::InitialPass to cmState::GetGlobalProperty > because I can access the global generator from cmState as well... Yes. > move "VARIABLES" and "MACROS," though, I need access to

Re: [cmake-developers] Allow ALIAS of IMPORTED targets

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

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

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

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

Hi Domen, Thank you. However those two test are not mutually exclusive. I think having them on lintian is also a good thing. Best and thanks, Raffi Le 14/09/15 23:19, Domen Vrankar a écrit : I just realized that the permissions for the extra control files should be set in a different way

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

>> I just realized that the permissions for the extra control files should >> be set in a different way than for the md5sum checksum file. >> >> Please find attached the patch correcting this and the corresponding >> test that fires the problem. Thanks, applied the fix:

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

> 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

Re: [cmake-developers] Allow ALIAS of IMPORTED targets

> 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

Re: [cmake-developers] CMake user-provided manifest files

On 09/11/2015 03:02 PM, Brad King wrote: > On 09/11/2015 02:09 PM, Brad King wrote: >> I would be very happy to get rid of the vs_link_exe and vs_link_dll code. > > There is documentation here about what those are doing: > > https://msdn.microsoft.com/en-us/library/ms235591.aspx >

Re: [cmake-developers] Allow ALIAS of IMPORTED targets

Hi Michael, If this feature can be supported for libraries and executables, it will be perfect for me. Thank you. Marc On 12/09/15 23:48, "cmake-developers on behalf of Michael Scott" wrote: >Hi, > >I'm planning

Re: [cmake-developers] find_program HINTS no longer preferred over PATH

Any news on this subject? I think it is a critical bug because behaviour is broken. So I cannot rely on find_executable anymore to get the expected program! Marc On 09/09/15 20:20, "Brad King" wrote: >On 09/09/2015 11:50 AM, Chuck Atkins wrote: >> From what I can

Re: [cmake-developers] Python extension to FindProtobuf

I now added documentation, removed ARGS and GENERATED property. -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Freitag, 11. September 2015 20:33 To: Andreas Bergmeier Cc: Rolf Eike Beer; cmake-developers@cmake.org Subject: Re: [cmake-developers] Python extension

Re: [cmake-developers] Listing all targets

Brad King wrote: > On 09/14/2015 11:46 AM, David Cole wrote: >> (1) I see how I can easily move "COMPONENTS" from >> cmGetCMakePropertyCommand::InitialPass to cmState::GetGlobalProperty >> because I can access the global generator from cmState as well... > > Yes. I assume you're thinking of

Re: [cmake-developers] [PATCH] Features: Only enable C11 support on GCC >= 4.9.

On 09/14/2015 01:53 PM, Raphael Kubo da Costa wrote: > Especially if you take into account the > CMAKE_CXX11_STANDARD_COMPILE_OPTION argument, one could argue that this > is about choosing how strict CMake should be when determining whether a > compiler implements a standard: enabling C++11

Re: [cmake-developers] [PATCH] Features: Only enable C11 support on GCC >= 4.9.

Stephen Kelly writes: > Raphael Kubo da Costa wrote: > >> Adjust the GCC feature detection code to only consider C11 support to >> exist on GCC >= 4.9. > > If you do that you must remove the definition of > CMAKE_CXX11_STANDARD_COMPILE_OPTION for GNU < 4.8.1 too. [...] >

Re: [cmake-developers] find_program HINTS no longer preferred over PATH

On 09/14/2015 02:00 PM, Alan W. Irwin wrote: > Because this find regression is against 3.1.3 from what Marc said, may > I assume you are planning to include the fix for this regression in > both future cmake-3.2.x and 3.3.y releases? We may backport it for a possible 3.3.2 but there will be no

Re: [cmake-developers] [PATCH] Features: Only enable C11 support on GCC >= 4.9.

Brad King writes: > In this case CMake itself cannot build with C11 on this compiler/platform > combination so we should not try to do so. We already have some checks > here: > > http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=CMakeLists.txt;hb=v3.3.1#l39 > > to decide

Re: [cmake-developers] find_program HINTS no longer preferred over PATH

On 2015-09-14 10:51-0400 Brad King wrote: On 09/14/2015 03:05 AM, CHEVRIER, Marc wrote: Any news on this subject? Chuck has had a fix in 'next' for a few days: find_*: Fix search order when the environment duplicates some HINTS http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ec8e5fb3

Re: [cmake-developers] [PATCH] Features: Only enable C11 support on GCC >= 4.9.

On 09/14/2015 02:29 PM, Raphael Kubo da Costa wrote: > Do you mean checking for FreeBSD and compiler version? I thought it'd be > too specific for upstream and was just going to make it be built with a > different standard (or no standard) on FreeBSD itself. I meant to add a try_compile check

Re: [cmake-developers] [PATCH] Features: Only enable C11 support on GCC >= 4.9.

Raphael Kubo da Costa wrote: > Stephen Kelly writes: > >> Raphael Kubo da Costa wrote: >> >>> Adjust the GCC feature detection code to only consider C11 support to >>> exist on GCC >= 4.9. >> >> If you do that you must remove the definition of >>