[CMake] Problem with circular dependencies

[Tyler Roscoe]

On Thu, May 28, 2009 at 10:03:11PM +0300, Dmytro Ovdiienko wrote:
> That was just a sample. CMake  can build it correctly, if you specify full
> path to the include directlry.
> 
> If you root CMakeLists.txt declares ROOT_PRJ you can write following in the
> A project.
> 
> INCLUDE_DIRECTORIES(
>   ${ROOT_PRJ_SOURCE_DIR}/B
>  )
> 
> And following in the B project
> 
> INCLUDE_DIRECTORIES(
>   ${ROOT_PRJ_SOURCE_DIR}/A
>  )

This is how I would do it. Either this, or just define A_SOURCE_DIR and
B_SOURCE_DIR in your top-level CMakeLists.

> A and B are static libraries. The order static libraries building has no
> mater.

Not true. Typically I interpret "dependencies" in this context to
describe a situation where source files in B rely on symbols in libA.
Therefore, libA must be available so that we can compile (and link)
libB. In this situation, libA obviously must be built before libB.

> It is defined if B folder is processed before A folder. But then
> A_SOURCE_DIR is not defined in the B project (circular dependency)

Ok, now I see what you mean. As noted above, I would move the dependency
up to the top level to prevent this loop.

I still don't understand how you would expect CMake to handle this
situation.

> But... why does TARGET_LINK_LIBRARIES work correctly? You can pass not
> loaded-yet project name to TARGET_LINK_LIBRARIES.

I think my favorite pop superstar-nee-software developer Mike Jackson
already addressed this point (just because libs and targets happen to
have the same name doesn't mean that they are the same concept).

tyler