[CMake] ProjectConfig.cmake, export() and multiple libraries

[Jérémie Delaitre]

Hi all,

I have a project which provides a set of shared libraries, some libraries
being dependent on other ones:

For example:
libcore
libmodule1 -> libcore
libmodule2 -> libcore
libmoduleA -> libmodule1

As this is a CMake based project, I've read on the internet that I should
provide a ProjectConfig.cmake file to allow other CMake based projects to
use the libraries. So I tried to do that after reading the tutorial on the
CMake's wiki and I have a working ProjectConfig.cmake for an installed tree
which contains all the targets (I did not succeed to have it working for an
in build tree though).

The problem is that I want each of my libraries to be "self-supported" (for
example, I'd like to use find_package() in module1 to find core). I want to
be able to have different version for each library which depends on specific
versions of the other libraries. If I am correct, that means I need to
generate one ProjectConfig.cmake and one ProjectConfigVersion.cmake for each
library.

This way, I should be able to create a project which does find_package(core
1.3) and find_package(module2 0.3) if it needs only the module2. But the
Module2Config.cmake tries do redeclare the "core" imported target which is
already created by the CoreConfig.cmake. Indeed I already have this problem
directly in the Module2's CMakeLists.txt as I tried to find_package(core
1.3) here in order to define the include directories and to link to the
core.

If I try to not export "core" when generating Module2Config.cmake, I get an
error telling me that "module2" depends on "core" so it must be exported.

So, to sum it up, I'd like each "module" to find its dependencies as if it
was third party libraries (installed tree and in build tree must be
supported). Then, everything should be ok to create a project which uses
only a few of the modules.

Any hints?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20111012/b25a7b31/attachment.htm>