Re: [cmake-developers] ninja command line options not propagated to ninja invocation for superbuild projects

2016-01-28 Thread Nicolas Desprès
On Thu, Jan 28, 2016 at 5:18 PM, Brad King wrote: > On 01/28/2016 11:04 AM, Taylor Braun-Jones wrote: > > Is this expected behavior, a known bug, or a new bug that I should file? > > Currently it is expected, but I don't think anyone has thoroughly > investigated it or

Re: [cmake-developers] ninja command line options not propagated to ninja invocation for superbuild projects

2016-01-28 Thread Brad King
On 01/28/2016 11:04 AM, Taylor Braun-Jones wrote: > Is this expected behavior, a known bug, or a new bug that I should file? Currently it is expected, but I don't think anyone has thoroughly investigated it or tried to implement it. IIRC it works in Makefile generators only because the make tool

Re: [cmake-developers] ninja command line options not propagated to ninja invocation for superbuild projects

2016-01-28 Thread Taylor Braun-Jones
On Sat, Mar 28, 2015 at 10:38 AM, Taylor Braun-Jones wrote: > > See htop screenshot below for an example of what I mean. Note that `ninja` in the original command line invocation is just a bash alias for ninja-build (the name of the ninja binary on Fedora-based systems) >

[cmake-developers] Namespaces

2016-01-28 Thread Pau Garcia i Quiles
Hello, I am adding several third-party projects as static libraries in my project. This is what I do: CMakeLists.txt | \-- 3rdparty | \ pugixml | \ QtZeroConf | \ QtDropBox | \ websocketpp In the root CMakeLists.txt, I have:

Re: [cmake-developers] Namespaces

2016-01-28 Thread Pau Garcia i Quiles
On Thu, Jan 28, 2016 at 7:17 PM, Stephen Kelly wrote: > > Has some kind of namespacing been considered for add_subdirectory? > > > > E. g. > > > > add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF) > > And what if someone builds your project with -DBUILD_SHARED=ON? Are you >

Re: [cmake-developers] Namespaces

2016-01-28 Thread Stephen Kelly
Pau Garcia i Quiles wrote: > CMake should wrap every variable defined under the directory added with > add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF) So, CMake needs to first determine what variables are used in the QtZeroConf directory (presumably without executing the cmake code there) and

Re: [cmake-developers] Namespaces

2016-01-28 Thread Ruslan Baratov via cmake-developers
On 29-Jan-16 01:17, Stephen Kelly wrote: Pau Garcia i Quiles wrote: add_subdirectory(pugixml/scripts) add_subdirectory(QtZeroConf) add_subdirectory(QtDropBox) add_subdirectory(websocketpp) This is an easy way to work with third-party dependences. Unfortunately this is 'easy, obvious and

Re: [cmake-developers] ninja command line options not propagated to ninja invocation for superbuild projects

2016-01-28 Thread Taylor Braun-Jones
On Thu, Jan 28, 2016 at 3:36 PM, Ben Boeckel wrote: > On Thu, Jan 28, 2016 at 15:15:58 -0500, Taylor Braun-Jones wrote: >> That's too bad. I understand the perspective of the Ninja developers, >> but it's not clear to me what the proposed alternative should be. >> Should

Re: [cmake-developers] Namespaces

2016-01-28 Thread Pau Garcia i Quiles
On Thu, Jan 28, 2016 at 9:58 PM, Alan W. Irwin wrote: > Your experience is contrary to mine. For example, in my epa_build > project (where I build all the many prerequisites of PLplot) I build a lot > of > different libraries (such as Qt5 and the GTK+ stack of

Re: [cmake-developers] Namespaces

2016-01-28 Thread Pau Garcia i Quiles
On Thu, Jan 28, 2016 at 8:21 PM, Stephen Kelly wrote: Pau Garcia i Quiles wrote: > > > CMake should wrap every variable defined under the directory added with > > add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF) > > So, CMake needs to first determine what variables are used

Re: [cmake-developers] ninja command line options not propagated to ninja invocation for superbuild projects

2016-01-28 Thread Taylor Braun-Jones
On Thu, Jan 28, 2016 at 11:28 AM, Nicolas Desprès wrote: > Unfortunately, Ninja won't offer it: > https://github.com/ninja-build/ninja/pull/1079 That's too bad. I understand the perspective of the Ninja developers, but it's not clear to me what the proposed alternative

Re: [cmake-developers] Namespaces

2016-01-28 Thread Ben Boeckel
On Thu, Jan 28, 2016 at 21:07:13 +0100, Pau Garcia i Quiles wrote: > I think it's just a matter of adding an "internal note" saying "OK, I'm > going to namespace variables from now on" in cmAddSubdirectoryCommand when > add_subdirectory contains NAMESPACE, and then modifying the literal of the >

Re: [cmake-developers] Namespaces

2016-01-28 Thread Stephen Kelly
Pau Garcia i Quiles wrote: > On Thu, Jan 28, 2016 at 8:21 PM, Stephen Kelly > wrote: > > > Pau Garcia i Quiles wrote: >> >> > CMake should wrap every variable defined under the directory added with >> > add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF) >> >> So, CMake needs

Re: [cmake-developers] Namespaces

2016-01-28 Thread Pau Garcia i Quiles
On Thu, Jan 28, 2016 at 9:19 PM, Ben Boeckel wrote: > I think the solution to your problem is to use INTERNAL cache variables > (for cache variables created by the third party project) or local > variables to override the cache variables in scope (which would likely >

Re: [cmake-developers] ninja command line options not propagated to ninja invocation for superbuild projects

2016-01-28 Thread Ben Boeckel
On Thu, Jan 28, 2016 at 15:15:58 -0500, Taylor Braun-Jones wrote: > That's too bad. I understand the perspective of the Ninja developers, > but it's not clear to me what the proposed alternative should be. > Should CMake be using the subninja[1] keyword to include the > build.ninja of External

Re: [cmake-developers] Namespaces

2016-01-28 Thread Alan W. Irwin
On 2016-01-28 19:58+0100 Pau Garcia i Quiles wrote: Unfortunately ExternalProject does not work well with find_package, e. g. this fill fail: CMakeLists.txt | \--- 3rdparty/CMakeLists.txt \--- server/CMakeLists.txt Where: 3rdparty/CMakeLists.txt contains ExternalProject_Add(QtZeroConf ...)

[cmake-developers] Review request: extract-cmMessenger branch

2016-01-28 Thread Stephen Kelly
Hi, I have pushed a extract-cmMessenger branch to my clone: https://github.com/steveire/CMake/commits/extract-cmMessenger The motivations are: * Decrease responsibilities of the cmake class. CMake uses too few classes for too many things * Make it possible to make add first-class handling of

[cmake-developers] [CMake 0015940]: There doesn't appear to be a cross-platform way to set flags to be used at compile time but not at link time

2016-01-28 Thread Mantis Bug Tracker
The following issue has been SUBMITTED. == https://public.kitware.com/Bug/view.php?id=15940 == Reported By:Guy Harris Assigned To:

Re: [cmake-developers] Namespaces

2016-01-28 Thread Alan W. Irwin
On 2016-01-28 23:25+0100 Pau Garcia i Quiles wrote: On Thu, Jan 28, 2016 at 9:58 PM, Alan W. Irwin wrote: Your experience is contrary to mine. For example, in my epa_build project (where I build all the many prerequisites of PLplot) I build a lot of different

[cmake-developers] [CMake 0015938]: RPATHs missing on link line for versioned libraries (.so.MAJOR.MINOR.PATCH)

2016-01-28 Thread Mantis Bug Tracker
The following issue has been SUBMITTED. == https://cmake.org/Bug/view.php?id=15938 == Reported By:Florian Rathgeber Assigned To:

[cmake-developers] [CMake 0015939]: Support for link time optimization for recent GCC compilers

2016-01-28 Thread Mantis Bug Tracker
The following issue has been SUBMITTED. == https://cmake.org/Bug/view.php?id=15939 == Reported By:pavel.odintsov Assigned To:

Re: [cmake-developers] Namespaces

2016-01-28 Thread Alan W. Irwin
On 2016-01-28 18:47+0100 Pau Garcia i Quiles wrote: [...] In the root CMakeLists.txt, I have: add_subdirectory(3rdparty) And in 3rdparty/CMakeLists.txt: add_subdirectory(pugixml/scripts) add_subdirectory(QtZeroConf) add_subdirectory(QtDropBox) add_subdirectory(websocketpp) This is an easy

Re: [cmake-developers] Namespaces

2016-01-28 Thread Stephen Kelly
Pau Garcia i Quiles wrote: > add_subdirectory(pugixml/scripts) > add_subdirectory(QtZeroConf) > add_subdirectory(QtDropBox) > add_subdirectory(websocketpp) > > This is an easy way to work with third-party dependences. Unfortunately this is 'easy, obvious and wrong'. > My problem comes from the