<div dir="ltr"><div>Hello Sven, Raymond.<br><br>On 28 June 2016 at 16:07, Sven Baars <span dir="ltr"><<a href="mailto:s.baars@rug.nl" target="_blank">s.baars@rug.nl</a>></span> wrote:<br>> 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.<br><br></div><div>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.<br><br><br>On 28 June 2016 at 16:07, Sven Baars <span dir="ltr"><<a href="mailto:s.baars@rug.nl" target="_blank">s.baars@rug.nl</a>></span> wrote:<br>> 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<br>> 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.<br><br>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.<br></div><div class="gmail_extra"><br><div><br>On 28 June 2016 at 17:19, Raymond Wan <span dir="ltr"><<a href="mailto:rwan.work@gmail.com" target="_blank">rwan.work@gmail.com</a>></span> wrote:<br>> I think if I were presented with the same problem as Sven, I'd <...> Or, if that wasn't possible, use ExternalProject.<br>> It's inefficient in terms of disk space, but at least A (assuming A depends on B) will be built correctly.<br><br></div>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 =(.<br><br></div><div class="gmail_extra">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.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>