[CMake] Problem with circular dependencies

[Dmytro Ovdiienko]

Hello Tyler,

Please find my comments below.

2009/5/29 Tyler Roscoe <tyler at cryptio.net>

> 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.
>

So, you have to support additional file. You should remove extra variable
from that CMakeLists.txt after you removed project. You have to add variable
after you add new project. It is possible to get inconsistant file, so far.


>
> 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.
>

Did not get. What do you mean?


>
> This doesn't help with your ordering problem.
>

Yeah. By David Cole I should merge A and B. But support right ordering of 30
projects... that may be not trivial.


>
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090529/4a1528b5/attachment.htm>