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

[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 tried to implement it.  IIRC it works in Makefile
> generators only because the make tool does it under the hood when
> one uses $(MAKE) in a makefile to run another make.  It is a feature
> of the build tool itself, not of CMake.  Unless Ninja offers some
> equivalent it may not be possible.
>
> Unfortunately, Ninja won't offer it:
https://github.com/ninja-build/ninja/pull/1079

-- 
Nicolas Desprès
-- 

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] ninja command line options not propagated to ninja invocation for superbuild projects

[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 does it under the hood when
one uses $(MAKE) in a makefile to run another make.  It is a feature
of the build tool itself, not of CMake.  Unless Ninja offers some
equivalent it may not be possible.

-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] ninja command line options not propagated to ninja invocation for superbuild projects

[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)
>
> Should I expect to see the -l3 option to be propagated automatically to
the sub projects of my superbuild? Or do I need to do some special cmake
configuration to make this happen? Or is this just a known issue?

I'm still seeing this behavior with CMake 3.4.1. Here's a friendlier
plaintext representation of the previous htop screenshot snippet:

ninja -l3
└── /usr/bin/ninja-build
├── /usr/bin/ninja-build
└── /usr/bin/ninja-build

Is this expected behavior, a known bug, or a new bug that I should file?
Note that this example shows the -l option not being propagated, but I
think all of the following Ninja options should be propagated:

  -l N do not start new jobs if the load average is greater than N
  -n   dry run (don't run commands but act like they succeeded)
  -v   show all command lines while building
  -d stats print operation counts/timing info
  -d explain   explain what caused a command to execute
  -t clean clean built files
  -t commands  list all commands required to rebuild given targets

Thanks,
Taylor
-- 

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

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

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 way to work with third-party dependences.

My problem comes from the fact several of these third-party libraries use
common variable names, e. g. BUILD_SHARED, BUILD_TESTS, etc).

Has some kind of namespacing been considered for add_subdirectory?

E. g.

add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF)

Which would lead to all the variables defined QtZeroConf/CMakeLists.txt
having a QTZEROCONF_ prefix, e. g. instead of BUILD_SHARED it would now be
QTZEROCONF_BUILD_SHARED.

Or, as an alternative:

add_subdirectory QtZeroConf NAMESPACE QtZeroConf)

and variables would be prefixed by QtZeroConf::, e. g. BUILD_SHARED would
now be QtZeroConf::BUILD_SHARED.

Does that sound sensible?



-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
-- 

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

[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
> going to use
>
>  set(QTZEROCONF_BUILD_SHARED ${BUILD_SHARED})
>  add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF)
>
> for every variable you're wrapping? Or do you want cmake to do that for
> every variable in scope when the directory is added? How would cmake decide
> which variables to namespace?
>
>
CMake should wrap every variable defined under the directory added with
add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF), no need for me to
manually wrap anything.



> You should use ExternalProject instead, or fork the buildsystem of those
> projects to integrate them into your project. Not that I recommend the
> latter for you though :). That's what cmake does when integrating 3rd party
> code.
>
>
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 ...)

and

server/CMakeLists.txt contains find_package(QtZeroConf)

This can be alleviated by using Hunter ( https://github.com/ruslo/hunter ),
by modifying the third-party CMakeLists.txt ( https://coderwall.com/p/y3zzbq
) or by manually setting the imported library location (
http://mirkokiefer.com/blog/2013/03/cmake-by-example/) but it's cumbersome.
My solution is much, much easier and requires no modification at all to the
third-party.

In fact, I think in addition to add_subdirectory( ... NAMESPACE ... ),
there should be something like find_package( QtZeroConf EXTERNAL_PROJECT
QtZeroConf), indicating the package is built by means of ExternalProject
and therefore, finding the package should be delayed until after that
external project has been built. That would make the tricks above
unnecessary.


-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
-- 

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

[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 then wrap 
the variables, then execute the cmake code? 

I must be missing something. I don't think that's possible.

> 3rdparty/CMakeLists.txt contains ExternalProject_Add(QtZeroConf ...)
> 
> and
> 
> server/CMakeLists.txt contains find_package(QtZeroConf)

I think you need:

 ExternalProject_Add(3rdparty/Whatever ...)
 ExternalProject_Add(3rdparty/QtZeroConf ...)
 ExternalProject_Add(server ...)

and pass appropriate args to the latter, including where to look for 
dependencies etc (and dependencies among the ExternalProjects).

You might not like this solution, but as far as I know it is the only 
correct solution built into CMake.

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

[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 wrong'.
This is wrong because of CMake limitations. Actually I was thinking 
about "namespacing" subdirectories too. From my point of view we can add 
namespace prefix every time when command 'project' called.

Project Foo:

== standalone ==
project(Foo)
add_library(foo ...) # add target foo

== as a subdirectory ==
project(Boo)
add_subdirectory(Foo)
# target Foo::foo

Since regular variables has different scope there is no need to do any 
updates for them, we need only to do something with globals: targets, 
cache variables, global properties (?).



My problem comes from the fact several of these third-party libraries use
common variable names, e. g. BUILD_SHARED, BUILD_TESTS, etc).

And indeed this is why.


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
going to use

  set(QTZEROCONF_BUILD_SHARED ${BUILD_SHARED})
  add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF)

for every variable you're wrapping? Or do you want cmake to do that for
every variable in scope when the directory is added? How would cmake decide
which variables to namespace?
I think this can be solved by adding extra suboptions to 
add_subdirectory command.




You should use ExternalProject instead, or fork the buildsystem of those
projects to integrate them into your project. Not that I recommend the
latter for you though :). That's what cmake does when integrating 3rd party
code.
As far as I understand `add_subdirectory(3rdParty/package)` approach 
used in CMake sources:
* zlib: 
https://github.com/Kitware/CMake/blob/5335d275527d4f58e4f2992d307c1c62cd94dd3c/CMakeLists.txt#L306
* curl: 
https://github.com/Kitware/CMake/blob/5335d275527d4f58e4f2992d307c1c62cd94dd3c/CMakeLists.txt#L337
* bzip2: 
https://github.com/Kitware/CMake/blob/5335d275527d4f58e4f2992d307c1c62cd94dd3c/CMakeLists.txt#L355


Ruslo
--

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] ninja command line options not propagated to ninja invocation for superbuild projects

[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 CMake be using the subninja[1] keyword to include the
>> build.ninja of External Projects?
>
> That would be possible with the work that's been done here:
>
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15364

Awesome. Nothing left to be said in this thread. I'll start following that one.

Taylor
-- 

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

[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 libraries) using
> ExternalProject_Add, and I don't experience any difficulties using
> find_package to find the installed results.
>
> I assume find_package should work well with ExternalProject_Add for
> you as well so long as (a) all your ExternalProject(s) are configured
> to do both a build and install (not just a build), and (b) you are
> being careful in server/CMakeLists.txt to set PATH,
> CMAKE_LIBRARY_PATH, CMAKE_INCLUDE_PATH, and PKG_CONFIG_PATH
> consistently with the install prefix used for the ExternalProject(s).
>
>
It works well for you because you actually have two things there:


   - PlPlot
   - A superbuild that builds the dependencies required to build PlPlot,
   and then, PlPlot itself by way of ExternalProject_Add (using
   download_command = copy the source code from some directory to another)


But what I would like to do with ExternalProject_Add (and please note this
is a different topic than what I started the thread for) is to avoid that
superbuild:


CMakeLists.txt
|
\--- 3rdparty
|
\--- server
|
\--- client
|
\--- app


Where the root CMakeLists.txt is something like this:

--8<---
project(myapp)

# ExternalProject used here to build dependencies
add_subdirectory(3rdparty)

# My software is built directly, not through a superbuild
add_subdirectory(server)
add_subdirectory(client)
add_subdirectory(app)
--8<---


and 3rdparty/CMakeLists.txt would be something like this:

--8<---
include(ExternalProject)

# websocketpp
ExternalProject_Add(websocketpp
   SOURCE_DIR ${CMAKE_BINARY_DIR}/websocketpp
   DOWNLOAD_DIR ${MYAPP_DOWNLOADS_DIR}
   INSTALL_DIR ${MYAPP_INSTALL_DIR}
   URL ${websocketpp_URL}
   URL_MD5 ${websocketpp_MD5}
   CONFIGURE_COMMAND ${CMAKE_COMMAND}
-DCMAKE_INSTALL_PREFIX=${MYAPP_INSTALL_DIR} ${CMAKE_BINARY_DIR}/websocketpp
   LOG_DOWNLOAD 1
   LOG_UPDATE 1
   LOG_CONFIGURE 1
   LOG_BUILD 1
   LOG_TEST 1
   LOG_INSTALL 1
   )

# QtZeroConf
ExternalProject_Add(QtZeroConf
   SOURCE_DIR ${CMAKE_BINARY_DIR}/QtZeroConf
   DOWNLOAD_DIR ${MYAPP_DOWNLOADS_DIR}
   INSTALL_DIR ${MYAPP_INSTALL_DIR}
   GIT_REPOSITORY ${QtZeroConf_URL}
   CONFIGURE_COMMAND ${QT_QMAKE_EXECUTABLE} PREFIX=${MYAPP_INSTALL_DIR}
${CMAKE_BINARY_DIR}/QtZeroConf
   LOG_DOWNLOAD 1
   LOG_UPDATE 1
   LOG_CONFIGURE 1
   LOG_BUILD 1
   LOG_TEST 1
   LOG_INSTALL 1
   )
--8<---

Now I should be able to do:

server/CMakeLists.txt

--8<---
project(server)

find_package(websocketpp REQUIRED)
find_package(Boost REQUIRED COMPONENTS date_time system thread)

set(server_SOURCES main.cpp server.cpp)

add_executable(server ${server_SOURCES})
target_link_libraries(server ${WEBSOCKETPP_LIBRARY} ${Boost_LIBRARIES})
--8<---

That would feel natural, wouldn't it?

But that does not work unless I juggle with add_library(... IMPORTED) or I
use Hunter or alike.

In the end, neither the current behavior of add_subdirectory nor the
current behavior of ExternalProject_Add let me work in the seemingly most
natural way: tell CMake to build my dependencies, then immediately work on
my applications/libraries :-(

I would love to work on this, as Stephen suggested, but I just don't have
the time :-/


-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
-- 

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

[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 in the
> QtZeroConf
> directory (presumably without executing the cmake code there) and then wrap
> the variables, then execute the cmake code?
>
I must be missing something. I don't think that's possible.
>
>
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
variable in cmSetCommand.cxx (first argument to AddDefinition here in line
165):

this->Makefile->AddDefinition(variable, value.c_str());

https://github.com/Kitware/CMake/blob/master/Source/cmSetCommand.cxx#L165


> 3rdparty/CMakeLists.txt contains ExternalProject_Add(QtZeroConf ...)
> >
> > and
> >
> > server/CMakeLists.txt contains find_package(QtZeroConf)
>
> I think you need:
>
>  ExternalProject_Add(3rdparty/Whatever ...)
>  ExternalProject_Add(3rdparty/QtZeroConf ...)
>  ExternalProject_Add(server ...)
>
> and pass appropriate args to the latter, including where to look for
> dependencies etc (and dependencies among the ExternalProjects).
>
> You might not like this solution, but as far as I know it is the only
> correct solution built into CMake.
>
>
The only thing I like about that solution is it's doable today with CMake.
But I think my approach would prove much easier and direct for developers
using CMake: add_subdirectory(dir NAMESPACE blah) and find_package(whatever
EXTERNAL_PROJECT epwhatever).

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
-- 

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] ninja command line options not propagated to ninja invocation for superbuild projects

[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 should be.
Should CMake be using the subninja[1] keyword to include the
build.ninja of External Projects?

[1] https://ninja-build.org/manual.html#ref_scope
-- 

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

[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
> variable in cmSetCommand.cxx (first argument to AddDefinition here in line
> 165):
> 
> this->Makefile->AddDefinition(variable, value.c_str());

This is not the only place variables are created.

> The only thing I like about that solution is it's doable today with CMake.
> But I think my approach would prove much easier and direct for developers
> using CMake: add_subdirectory(dir NAMESPACE blah) and find_package(whatever
> EXTERNAL_PROJECT epwhatever).

As mentioned elsewhere, what about things like find_package() in the
subdirectory? Do they get namespaced as well? Is a cache overflowing
with png_ZLIB_LIBRARY, sqlite3_ZLIB_LIBRARY, and so on sensible? Is
having to set all of them if the library is in a weird place something
you want users to have to do? What about custom properties (be it on
targets, directories, global)? Do they also get namespaced?

Functions are globally scoped, so what namespace do they apply? What if
they have controlling variables from their module which is now
namespaced, but called from a non-namespaced location?

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
work for BUILD_SHARED_LIBS or ENABLE_TESTING).

--Ben
-- 

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

[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 to first determine what variables are used in the
>> QtZeroConf
>> directory (presumably without executing the cmake code there) and then
>> wrap the variables, then execute the cmake code?
>>
> I must be missing something. I don't think that's possible.
>>
>>
> 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
> variable in cmSetCommand.cxx (first argument to AddDefinition here in line
> 165):
> 
> this->Makefile->AddDefinition(variable, value.c_str());
> 
> https://github.com/Kitware/CMake/blob/master/Source/cmSetCommand.cxx#L165

I'm happy to provide guidance if you start writing a patch and find that it 
is a realistic approach, but I still don't think this is possible.

What do you do when third party code contains

 set(SOMETHING foo bar)
 foreach(thing ${SOMETHING})
 ...
 endforeach()

?

Are you going to change every read of a variable to prefix it with a 
namespace?

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

[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
> work for BUILD_SHARED_LIBS or ENABLE_TESTING).
>
>
Unfortunately, using INTERNAL cache variables requires me to modify the
third-party library, which is exactly what I do not want to do. I want to
be able to drop the third-party in a folder, add_subdirectory and form then
on, use it.


-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
-- 

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] ninja command line options not propagated to ninja invocation for superbuild projects

[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 Projects?

That would be possible with the work that's been done here:

http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15364

--Ben
-- 

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

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

and

server/CMakeLists.txt contains find_package(QtZeroConf)


Hi Pau:

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 libraries) using
ExternalProject_Add, and I don't experience any difficulties using
find_package to find the installed results.

I assume find_package should work well with ExternalProject_Add for
you as well so long as (a) all your ExternalProject(s) are configured
to do both a build and install (not just a build), and (b) you are
being careful in server/CMakeLists.txt to set PATH,
CMAKE_LIBRARY_PATH, CMAKE_INCLUDE_PATH, and PKG_CONFIG_PATH
consistently with the install prefix used for the ExternalProject(s).

By the way, some versions of CMake-3.x.y have been plagued by
substantial find issues, and your bad experience with find_package
might be related to those issues.  However, I haven't experienced any
major find issues with CMake-3.3.2 so you might want to shift to that
version if you aren't using it already.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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] Review request: extract-cmMessenger branch

[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 messages about
missing packages (for example) to cmake-gui by making methods on
cmMessenger virtual and subclassing
* Make it possible to emit messages through the daemon (also by
subclassing) together with backtrace and message type, relieving clients
from having to parse the text.

I'm interested in what you think of the approach.

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

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=15940 
== 
Reported By:Guy Harris
Assigned To:
== 
Project:CMake
Issue ID:   15940
Category:   CMake
Reproducibility:N/A
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-01-28 18:32 EST
Last Modified:  2016-01-28 18:32 EST
== 
Summary:There doesn't appear to be a cross-platform way to
set flags to be used at compile time but not at link time
Description: 
It appears that if a flag is added to CMAKE_C_FLAGS, it will be used not only at
compile time but also at link time, at least for some platform/compiler
combinations.

Many such flags are, at best, not helpful at link time, and clutter the command
line used for linking.  Some might also not work at link time.

Unix make, and autotools, keep compiler flags (CFLAGS/CXXFLAGS/etc.) and linker
flags (LDFLAGS) separate.  CMake should provide a way to do the same.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-01-28 18:32 Guy Harris 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] Namespaces

[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 libraries (such as Qt5 and the GTK+ stack of libraries) using
ExternalProject_Add, and I don't experience any difficulties using
find_package to find the installed results.

I assume find_package should work well with ExternalProject_Add for
you as well so long as (a) all your ExternalProject(s) are configured
to do both a build and install (not just a build), and (b) you are
being careful in server/CMakeLists.txt to set PATH,
CMAKE_LIBRARY_PATH, CMAKE_INCLUDE_PATH, and PKG_CONFIG_PATH
consistently with the install prefix used for the ExternalProject(s).



It works well for you because you actually have two things there:


  - PlPlot
  - A superbuild that builds the dependencies required to build PlPlot,
  and then, PlPlot itself by way of ExternalProject_Add (using
  download_command = copy the source code from some directory to another)


Hi Pau:

Yes, that is a good summary, although I would add that all the
dependencies are handled properly.  So the result is you can epa_build
any library (such as PLplot) within the epa_build project and the
subset of the epa_builds corresponding to its dependencies
automatically occur first, but only once (unless some change is made
in one of the dependent epa_builds).  The dependency handling for a
given project is a bit complex, but, as you might expect, the
dependency logic is essentially identical for each project so I could
implement it using a CMake function.  So the net result is the
CMakeLists.txt file for each epa_build project is quite short
consisting of establishing the list of dependencies, calling the
dependency-handling function, setting up ExternalProject_Add for a
given project, and then calling that routine.


But what I would like to do with ExternalProject_Add (and please note this
is a different topic than what I started the thread for) is to avoid that
superbuild:


You do have to build and install the external software once in any case so I
suspect your motivation to avoid the "superbuild" is it keeps getting
unnecessarily repeated in your case.  But that should not be an issue if you 
deal
with the dependencies correctly, see remarks above.

I do take your point this is a different topic than your original one so
if you want to continue this discussion, we should probably do it off list.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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 0015938]: RPATHs missing on link line for versioned libraries (.so.MAJOR.MINOR.PATCH)

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=15938 
== 
Reported By:Florian Rathgeber
Assigned To:
== 
Project:CMake
Issue ID:   15938
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2016-01-28 09:30 GMT
Last Modified:  2016-01-28 09:30 GMT
== 
Summary:RPATHs missing on link line for versioned libraries
(.so.MAJOR.MINOR.PATCH)
Description: 
When linking against a library using the *full path* to a *versioned* .so file,
the RPATH (-Wl,-rpath,/full/path or equivalent) is missing from the link line.
It *does* work when using the non-versioned library ending in .so

Steps to Reproduce: 
Build CGAL 4.7, which exports libCGAL.so.11.0.1 as CGAL_LIBRARY in its
CGALExports.cmake

Use in your CMake project similar to the following:

...

find_package( CGAL REQUIRED )

...

target_link_libraries( my_exe ${CGAL_LIBRARY} )

Additional Information: 
Looks like a "parser error" to me, potentially regex too narrow?
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-01-28 09:30 Florian RathgeberNew 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

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

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=15939 
== 
Reported By:pavel.odintsov
Assigned To:
== 
Project:CMake
Issue ID:   15939
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   high
Status: new
== 
Date Submitted: 2016-01-28 07:40 EST
Last Modified:  2016-01-28 07:40 EST
== 
Summary:Support for link time optimization for recent GCC
compilers
Description: 
Hello!

I tried to play with INTERPROCEDURAL_OPTIMIZATION on cmake 3.4.2 but found it's
not working really well.

After short grep'ing over source I have found there are not support for this
option for non Intel compilers.

So I could like to ask for LTO support for cmake for GCC compiler.  Recent GCC
compilers do very-very big amount of code optimization and it's very important
to have this option in project build system.

Thanks a lot!
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-01-28 07:40 pavel.odintsov 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] Namespaces

[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 way to work with third-party dependences.

My problem comes from the fact several of these third-party libraries use
common variable names, e. g. BUILD_SHARED, BUILD_TESTS, etc).

Has some kind of namespacing been considered for add_subdirectory?


I cannot answer that question, but I suggest instead that the proper
way to deal with third-party libraries with no name contamination from
the parent project is simply to build and install them using the
ExternalProject approach.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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

[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 fact several of these third-party libraries use
> common variable names, e. g. BUILD_SHARED, BUILD_TESTS, etc).

And indeed this is why.

> 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 
going to use 

 set(QTZEROCONF_BUILD_SHARED ${BUILD_SHARED})
 add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF)

for every variable you're wrapping? Or do you want cmake to do that for 
every variable in scope when the directory is added? How would cmake decide 
which variables to namespace?

You should use ExternalProject instead, or fork the buildsystem of those 
projects to integrate them into your project. Not that I recommend the 
latter for you though :). That's what cmake does when integrating 3rd party 
code.

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