Re: [cmake-developers] Namespaces

[Stephen Kelly]

Pau Garcia i Quiles wrote:

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

I did something like that a few months ago:

 https://github.com/Ableton/aqt-cassowary/blob/master/src/CMakeLists.txt

However, that's not a pattern which scales I think. It requires the host to 
know too much about the hosted, and could stop working in the future (cmake 
should maybe emit an error if the LOCATION specified in an IMPORTED target 
does not exist).

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

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

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