[CMake] Problem with circular dependencies

[Tyler Roscoe]

On Fri, May 29, 2009 at 01:45:45AM +0430, Dmytro Ovdiienko wrote:
> I prefer encapsulation of all library related information into the library.
> Only library know where it is located, where are public headers are located,
> where lib file is located. The way you proposed violates this encapsulation.

Fair enough. What I actually do is I have a separate file CMakeVars.txt
where I define variable (such as source directories). This file is
include()d both by the subproject (libA) and by any top-level projects
that add_subdirectory() that subproject.

You could do the same thing with [set|get]_target_properties(). I do
this in a few spots where my CMakeVars pattern doesn't work.

This doesn't help with your ordering problem.

> I expected CMake to replace B_SOURCE_DIR with <root>/B and A_SOURCE_DIR with
> <root>/A. Thats all.

Well as you concisely stated at the beginning of this discussion, you
have a circular dependency. Software is bad at handling circular
dependencies, so it is your job as the human to jump in and decide how
to break it up. We have discussed a number of strategies for doing this.

tyler