[CMake] How do you handle recursive dependencies in CMake

[Cfyz]

Hello Sven, Raymond.

On 28 June 2016 at 16:07, Sven Baars <s.baars at rug.nl> wrote:
> Hence my question if there is some "right" way of doing this with CMake,
without all of the code I wrote to work around the problem.

I am under impression there is an important bit missing from CMake export
system. If some library has an unspecified set of dependencies (decided
during its configuration) then it will not be able to generate a config
file for find_package with CMake default tools alone. I think I will raise
it as an issue at the main CMake issue tracker after some more
investigation.


On 28 June 2016 at 16:07, Sven Baars <s.baars at rug.nl> wrote:
> I also wrote a lot of homebrew code you mentioned at the end of the post,
but it indeed always seems to always break something for some user of the
code
> In the mean time I'll have a look at the code you wrote, but it seems
very similar to something I already had, which broke for some users.

The code examples and what I've mentioned earlier are just pieces of the
possible solution. A complete export has a lot of nuances (e. g.
versioning, build configurations, etc.) and is unlikely to work flawlessly
right from the start. But think it might be worthwhile to try and make such
helper module somewhere on github.


On 28 June 2016 at 17:19, Raymond Wan <rwan.work at gmail.com> wrote:
> I think if I were presented with the same problem as Sven, I'd <...> Or,
if that wasn't possible, use ExternalProject.
> It's inefficient in terms of disk space, but at least A (assuming A
depends on B) will be built correctly.

What I'm trying to solve (and what Sven's problem looks very similar to) is
more about keeping the information about dependencies. You've mentioned
that yourself in the linked discussion: the real problem are projects with
complex tree-like dependencies, more than one edge deep. And once those
dependencies become optional and configurable, things break completely. It
is impossible to search for the dependency you don't even know about =(.

ExternalProject has a somewhat similar flaw. I've tried once to use it for
FFmpeg and found out that ExternalProject does its work at the build step.
On the configure step there is nothing yet and consequently there is no way
to figure out what will be needed to link against the library. Even though
FFmpeg does report its dependencies (via pkg-config) later after being
installed, it is too late. There was a workaround with two-step build but
that looked ugly, scaled even worse and I've settled on separate builds and
custom find modules.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160628/5dcc62d1/attachment.html>