[CMake] Problem with circular dependencies

[Dmytro Ovdiienko]

Tyler,

Please find my comments below.

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

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

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.

Do you use .NET? Do you know how it is easy to use assemblies. There are no
lib files, no headers. You just provide linker with one DLL file. It
contains all needed information to build project.

I want to use libraries like assembly. Target can store all information
about PUBLIC_HEADERS and lib files. You should just say "Library A depends
on library B". CMake should extract information about header files and lib
files from A and place it to B.



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

Yeah, source files of the B depends on symbols from libA. But linker do not
need to resolve all dependencies while it creates lib files. Sure, we are
not talking about cases when libA are linked directly to 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.
>

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


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


Best regards

Dima
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090529/b3bf7e57/attachment.htm>