[CMake] How do you handle recursive dependencies in CMake

[Raymond Wan]

On Wed, Jun 29, 2016 at 3:23 AM, Cfyz <cfyzium at gmail.com> wrote:
> 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 =(.


I agree that what we're observing is a problem, but I don't think it
is that big.  There are at least 3 solutions discussed so far:

1)  The "ad-hoc" method I first mentioned by setting
CMAKE_LIBRARY_OUTPUT_DIRECTORY.
2)  ExternalProject which will grab a repository and build it.
3)  Some Find_Package () mechanism that will do a search for it.
4)  Your option of including *.cmake files that provide the paths
[sorry, I might have misunderstood it].

If we have some kind of transitive dependency:  A depends on B; B depends on C.

Then when we build A, we don't really need to know [in detail] that
this transitive dependency exists (*).  All the compiler needs to know
is where is B and where is C.  And if B and C are in the same
directory (i.e., a system-level directory), that's fine.

Suppose B and C are in two different directories.  I don't know if
it's common, but often, I see install scripts provide a symbolic link
from the system-level directory to where B and C are

In Sven's case (sorry to put you on the spot, Sven!  :-) ), the 3
options don't work because:

1)  Modules are in different source trees.
2)  Duplication between users on a super-computer.
3)  Too many combinations of Find_Package ().
4)  Seems ad-hoc?

Though not perfect, either (2) or (3) could solve Sven's problem.  For
(2), ignore duplication.  For (3), how about something like what
Find_Boost does?  It searches for system-level directories, but you
can nudge it by setting an environment variable (i.e., BOOST_ROOT)
where it will search first.  This means each user will have to set an
environment variable (or set it on the command-line of CMake with -D).

Hmmmmm, I *think* any of this is fine (for Sven's problem), but if it
isn't then perhaps I'm misunderstanding the problem...

Ray

(*)  At least, the order to the archives in target_link_libraries have
to be correct.  But that is done once by the CMakeLists.txt writer and
not something the end user needs to worry about.