[CMake] Problem with circular dependencies

David.Karr at L-3COM.COM David.Karr at L-3COM.COM
Fri May 29 10:16:06 EDT 2009


Dmytro Ovdiienko <dmitriy.ovdienko at gmail.com>:
> Yeah. By David Cole I should merge A and B. But support right ordering
of 30
> projects... that may be not trivial.

Here is something that confuses me.  At the beginning of this
discussion, you said there was a CMakeLists.txt file in the <root>
directory: that is, you have <root>/CMakeLists.txt.  Then I infer from
your description that you also have a file <root>/A/CMakeLists.txt (do I
infer this correctly?) in order to build a static library in <root>/A,
and in <root>/A/CMakeLists.txt you have (in effect, after substitution
for variables) the command:

PROJECT(A)

Similarly you have a file <root>/B/CMakeLists.txt in which you have (in
effect) the command:

PROJECT(B)

Now, as you requested, I am not going to ask why B depends on A while A
depends on B.  But I will ask this: why do you need two PROJECT
commands?  Why not remove both these commands and instead place this
command in <root>/CMakeLists.txt:

PROJECT(MyRootProject) 

If you had this command in <root>/CMakeLists.txt, then you could write
this in <root>/A/CMakeLists.txt:

INCLUDE_DIRECTORIES(
  ${MyRootProject_SOURCE_DIR}/B
)

and you could write this in <root>/B/CMakeLists.txt:

INCLUDE_DIRECTORIES(
  ${MyRootProject_SOURCE_DIR}/A
)

Then ${MyRootProject_SOURCE_DIR}/B will become <root>/B after
substitution and ${MyRootProject_SOURCE_DIR}/A will become <root>/A,
which is what you said you wanted.  You don't need to refactor the
source code, just let CMake handle these directories the way they are
obviously designed, as one inseparable group of libraries.

David
 


More information about the CMake mailing list