[CMake] When should I use add_subdirectory and when ExternalProject?

David Cole dlrdave at aol.com
Tue Feb 5 15:03:29 EST 2013


 

 

 

-----Original Message-----
From: Alexander Neundorf <a.neundorf-work at gmx.net>
To: David Cole <dlrdave at aol.com>
Cc: cmake <cmake at cmake.org>
Sent: Tue, Feb 5, 2013 2:50 pm
Subject: Re: [CMake] When should I use add_subdirectory and when ExternalProject?


On Tuesday 05 February 2013, David Cole wrote:
> -----Original Message-----
> From: Alexander Neundorf <a.neundorf-work at gmx.net>
> To: cmake <cmake at cmake.org>
> Sent: Tue, Feb 5, 2013 1:09 pm
> Subject: Re: [CMake] When should I use add_subdirectory and when
> ExternalProject?
> 
> On Monday 04 February 2013, David Cole wrote:
> > The OpenChemistry project (
> > https://github.com/OpenChemistry/openchemistry ) is a very good example
> > of a SuperBuild project that builds all of its external dependencies via
> > ExternalProject, and then all of its git submodules ("internal
> > dependencies" perhaps ?) also via ExternalProject.
> > 
> > They use CMAKE_PREFIX_PATH both as a place to install all of the built
> > components, and as a place for find_package to find stuff that was built
> > by a previous ExternalProject_Add call.
> > 
> > Study how they do stuff in their CMakeLists files and then get back to us
> > here with more questions.
> 
> one thing I had trouble with is related to the install step.
> 
> With externalProject the install step happens at build time.
> If shared libraries are involved, the install destination should be the
> correct and final install destination, so that the RPATH of using projects
> will point to the correct location.
> This means that at build time I need to have the permissions to write to
> the final install destination (e.g. /opt/), i.e. typically root.
> 
> Is this correct or am I missing something ?
> 
> Alex
> --
> 
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> 
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
> 
> 
> 
> 
> You are correct, but you are coming at it from a Linux-biased perspective.
> 
> For developers on the project, this technique works as-is, in the build
> tree, and in the super-build's install tree, which is in a non-system,
> i.e., user writable location. That's true on all platforms.
> 
> If you are building the openchemistry projects for packaging on a Linux
> box, then you will use all the "system" packages, and not even build them
> as part of the super build. Each one has a flag for whether or not to use
> the system one or to build it.
> 
> For Mac and Windows installers, this technique works well, since all the
> built pieces of the super build are bundled up together as relocatable app
> installations.

How do relative packages actually work on the Mac with install_name ?
Is this always relative ?
I mean, if I have an application and build it against a shared lib, and then 
later on at install time that shared lib is at some other place, the apps 
doesn't find, does it ?
 
Alex



via BundleUtilities and fixup_bundle. Using @executable_path in bundled shared libraries...

At install time, that lib is going to be inside the app bundle. It is not going to be at some other place.


 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20130205/391cc0d6/attachment.htm>


More information about the CMake mailing list