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
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
