[CMake] RPM packaging dependencies expressed in subdirectories

[Thibault Hild]

Hello,

I'm quite new to CMake and after experimenting a bit, I am currently
considering a way to express RPM dependencies in subdirectories instead of
specifying them at the top level.
After googling a bit, I did not find something that fulfills my
expectations but I have probably missed a post or something in the CPack
documentation. If you already know of a discussion thread or explanation on
this particular subject, can you please redirect me to it ?

To clarify, I currently have the following source hierarchy:
________________________________________________________
[build at build src]$ ls -R
.:
CMakeLists.txt  hello  world

./hello:
CMakeLists.txt  hello.cpp

./world:
CMakeLists.txt  world.cpp  world.h
________________________________________________________


The top level CMakeLists.txt contains:
________________________________________________________
[build at build src]$ cat ./CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(cmake_testbed)

set(CMAKE_INSTALL_PREFIX "/some/where")

# use, i.e. don't skip the full RPATH for the build tree
set(CMAKE_SKIP_BUILD_RPATH  false)
# when building, don't use the install RPATH already
# (but later on when installing)
set(CMAKE_BUILD_WITH_INSTALL_RPATH false)
set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
# add the automatically determined parts of the RPATH
# which point to directories outside the build tree to the install RPATH
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH true)
# the RPATH to be used when installing, but only if it's not a system
# directory
list(FIND CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES
"${CMAKE_INSTALL_PREFIX}/lib" isSystemDir)
if("${isSystemDir}" STREQUAL "-1")
        set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
endif("${isSystemDir}" STREQUAL "-1")

add_subdirectory(world)
add_subdirectory(hello)

set(CPACK_PACKAGING_INSTALL_PREFIX "${CMAKE_INSTALL_PREFIX}")
set(CPACK_GENERATOR "RPM")
set(CPACK_RPM_PACKAGE_REQUIRES "ruby >= 1.8")

include(CPack)
________________________________________________________


As you can see, I am currently expressing a RPM dependency on ruby in the
top level CMakeLists.txt but in fact this dependency comes from the hello
subdirectory because hello.cpp states this:
________________________________________________________
[build at build src]$ cat hello/hello.cpp
#include "world.h"
#include <iostream>
#include <cstdlib>

using namespace std;

int main(int argc, char* argv[]) {
        cout << "hello " << world() << endl;
        system("/usr/bin/ruby --version");
        return 0;
}
________________________________________________________


hello/CmakeLists.txt current content is:
________________________________________________________
[build at build src]$ cat hello/CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(hello)
include_directories(${world_SOURCE_DIR})
add_executable(hello hello.cpp)
target_link_libraries(hello world)
install(TARGETS hello DESTINATION bin)
________________________________________________________


Is there a way to express this RPM dependency in "hello/CMakeLists.txt"
instead of "./CMakeLists.txt" ?

The common use case for this is the integration of multiple components
which would all comes with there own dependencies without requiring the
integrator to dig in each subdirectory in order to find its induced
dependencies (which are well known by the component's author).
I understand that this also raises the problem of multiple dependencies
over the same component (let say "hello" needs "ruby >=2.8" and "world"
needs "ruby >= 3.0"). I do not currently know how rpmbuild would behave if
he find two requirements on the same dependency (I would expect it to take
the stronger requirement i.e. "ruby >= 3.0" which is nonetheless not always
the right solution in case of a backward compatibility breakage).

Is anyone having the same kind of need over expressing packaging
dependencies (RPM or other)?
If so, did you find a way to express them in the CMakeLists.txt of the
subdirectories?

Thanks for reading me until the end, regards,

Thibault Hild
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20140716/9f14cabb/attachment-0001.html>