[CMake] Link something to future installed library

[David Demelier]

Le dimanche 10 mars 2013 17:14:01 Rolf Eike Beer a écrit :
> David Demelier wrote:
> > Hello,
> > 
> > I'm trying to make a common core library that will help creating modules,
> > my modules will link against it but this will not work as these modules
> > will link against the library in the binary build directory.
> > 
> > My CMakeLists.txt is quite complexe with a lot of subdirectories so I will
> > just reduce to a small example that explain my problem :
> > 
> > # My common library
> > file(GLOB COMMON "core/*")
> 
> GLOB will generate a list of all files that match the globbing expressions
> and store it into the variable. Globbing expressions are similar to regular
> expressions, but much simpler. If RELATIVE flag is specified for an
> expression, the results will be returned as a relative path to the given
> path. (We do not recommend using GLOB to collect a list of source files
> from your source tree. If no CMakeLists.txt file changes when a source is
> added or removed then the generated build system cannot know when to ask
> CMake to regenerate.)
> 
> > add_library(core SHARED ${COMMON})
> > install(TARGETS core DESTINATION "myapp/lib")
> > 
> > # Now create some modules
> > add_library(mod1 MODULE mod.cpp)
> > install(TARGETS mod1 DESTIONATION "myapp/lib/modules")
> > 
> > And then I would like mod1 to be linked to the future installed core
> > library.
> > 
> > I really want my common library to be a shared library, then everyone that
> > would like to create new modules can do it independently of this project.
> > 
> > Is there any workaround or possibilities to solve my issue?
> 
> When you install the modules, they will be linked against the install
> location. As long as they are in the build tree they will use the build tree
> location. So I guess there is no issue.
> 
> Eike
> --

Thanks for your answer, however target_link_libraries() my modules to the 
target of core will link to the build binary directory as expected :

markand at Melon .../src/magicstat-2/_build_ $ ldd modules/battery/battery.so
modules/battery/battery.so:
        libcore.so => 
/home/markand/work/src/magicstat-2/_build_/core/libcore.so (0x801204000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x801405000)
        libm.so.5 => /lib/libm.so.5 (0x801715000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x801936000)
        libc.so.7 => /lib/libc.so.7 (0x80081a000)

once installed..

markand at Melon .../src/magicstat-2/_build_ $ ldd 
/usr/local/lib/magicstat/modules/battery/battery.so
/usr/local/lib/magicstat/modules/battery/battery.so:
        libcore.so => not found (0)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x801204000)
        libm.so.5 => /lib/libm.so.5 (0x801514000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x801735000)
        libc.so.7 => /lib/libc.so.7 (0x80081a000)

The installation hierarchy are the same as the build directory :

build/core/libcore.so
build/modules/battery.so

and /usr/local/lib/magicstat/libcore.so
/usr/local/lib/magicstat/modules/battery/battery.so

A workaround I can make is building core as static AND shared library, link my 
modules to the static and install the shared for third party modules.. This 
may work but it's probably not the best solution.

Regards,
-- 
David Demelier