date:20150915

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

2015-09-15 Thread Raffi Enficiaud


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-15 Thread Domen Vrankar

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

2015-09-15 Thread CHEVRIER, Marc


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

2015-09-15 Thread CHEVRIER, Marc


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

2015-09-15 Thread Mantis Bug Tracker


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

2015-09-15 Thread Stephen Kelly

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

2015-09-15 Thread Stephen Kelly


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

2015-09-15 Thread Domen Vrankar

> 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

2015-09-15 Thread Andreas Bergmeier

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

2015-09-15 Thread James Johnston

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

2015-09-15 Thread Raffi Enficiaud


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 Enficiaud 
Date: 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

2015-09-15 Thread Mantis Bug Tracker


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

2015-09-15 Thread Mantis Bug Tracker


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

2015-09-15 Thread Mantis Bug Tracker


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.

2015-09-15 Thread Brad King

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

2015-09-15 Thread Tamás Kenéz

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 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.

2015-09-15 Thread Raphael Kubo da Costa

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

2015-09-15 Thread David Gobbi

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

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

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

[cmake-developers] [CPack][BUG] Fail to package with CPACK_INSTALLED_DIRECTORIES

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

[cmake-developers] [CMake 0015745]: Export target with multiple names

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

[cmake-developers] xcode7-defaults-to-c11 topic

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

Re: [cmake-developers] Python extension to FindProtobuf

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

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

[cmake-developers] [CMake 0015743]: get_filename_component turns real path to ABSOLUTE path

[cmake-developers] [CMake 0015744]: Spaces in paths with non-ASCII characters are not escaped when using Ninja

[cmake-developers] [CMake 0015746]: pkg_check_modules should document how to handle spaces in framework names

Re: [cmake-developers] [PATCH] Do not build CMake in C11 mode if _Thread_local support is broken.

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

[cmake-developers] [PATCH] Do not build CMake in C11 mode if _Thread_local support is broken.

[cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks

18 matches

Site Navigation

Mail list logo

Footer information