[CMake] modular builds / add_subdirectory for external directory / ExternalProject_Add / RHEL6

Derrick Karimi derrick.karimi at gmail.com
Wed Oct 31 09:07:08 EDT 2012


Hello,

I am trying to create a modular development environment.  My goal is to
have different source modules in separate source control projects.
Sometimes there will be dependencies between these modules.  I also will be
scooping in 3rd party projects and placing some kind of wrapper build
around it to make it conform to whatever standards I come up with to pull
off this build environment.  The main goal is to get and build a module
(and there by all its dependencies) with minimal requirements for a build
environment, and a minimal number of commands (On a fresh OS Install, git
project; mkdir bld; cd bld; cmake ../project; make )

I researched build tools, decided on cmake over scons and autotools
basically because it seemed popular, was on my base OS images, and it was
easy to use.

As I was researching how to pull off my goals, I came across the
ExternalProject_Add.  Unfortunately I am stuck with RHEL 6 right now, and
cmake 2.6 is all it supports, and this function appears to be added in 2.8

I investigated upgrading, which I didn't really want to do.  I wanted to do
development on almost any machine, and the one place I found an
experimental repo with cmake 2.8 built for RHEL 6 seemed risky.  Also I
build on machines without internet access, and didn't want to end up in RPM
hell trying to get it on, and end up with an expensive to replicate build
environment.

So I tried to work around the issue in 2.6 using a combination of
find_package and add_subdirectory.  One requirements I made up is that if
multiple paths in dependency tree share some parent, that parent is only
retrieved from source control and built once.  Yes I am ignoring custom
flags differing in dependent modules, but I don't anticipate that
requirement.

I tried add_subdirectory of an external directory, and I set the binary
directory too.  cmake completes without complaint, but then when I run
make, I get a "No rule to make target 'dependency.so', needed by
'currentproject'. Stop.  Google revealed that other people had this problem
too.  But any advice given to them I have tried and still no luck.

I have one more idea involving an unholy combination of prebuild custom
command launching git, cmake, make.  Make install would generate a
module-config.cmake and then I would call find_package on that.  It seems a
bit crazy to do that when this is all fixed in 2.8

I am looking for some advice on how to accomplish my goals.  Here is an
example of 3 modules that would be in my source control, and how I would
expect the directory layout to be.

+boost
  +include
  +lib
  boost-config.cmake

+core
  +src
    some.cpp
  CMakeLists.txt (depends on boost)

+app
 +src
   app.cpp
 CMakeLists.txt (depends on boost and core)

Now I would get app from source control and build and expect this layout

+work
  +app (same as above)
  +bld
    +core (same as above)
    +core_bld
      Makefile (and other cmake generated stuff)
    +boost (same as above)
    +boost_bld
      Makefile (and other cmake generated stuff)
    Makefile (and other cmake generated stuff)

But currently when I add_subdirectory of core from the app's CMakeLists.txt
I start running into trouble.  I briefly tried moving the dependency source
modules (core, boost) underneath the current module (app).  This didn't
work for me, but in theory I think it should as now add_subdirectory would
actually be adding a subdirectory, so I may just need to put some more
effort on it.  This went against my desire to keep the module directories
clean, the same as they are in source control, but I could live with this
if it works, I would just make an external subfolder in each module and
tell my source control to ignore it.

Does anyone have any advice for me?

--Derrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20121031/ff2f59cc/attachment.htm>


More information about the CMake mailing list