I have this same question. There doesn't seem to be a way to have these
imported target see other targets. I can pull the full path out for this
target, but it seems less elegant.
On Thu, Dec 22, 2011 at 11:08 AM, Marco Corvo marco.co...@pd.infn.itwrote:
Hi all,
I have a big project which can be used in two ways: either the user checks
out all the packages and makes a big make or he checks out only a subset
and build them linking against a given release, which is installed
somewhere else on his machine.
In this last option the libraries installed somewhere are trated as
external dependencies by the working packages. The problem I have comes
out when I have a transitive dependency.
To make an example, I check out two packages: package A, which builds a
static library and a binary and depends on an external library B, and a
package C.
The cmake code to make A know where to find libB.a is the following:
add_library(B STATIC IMPORTED)
set_target_properties(B PROPERTIES IMPORTED_LOCATION
/path/to/external/lib/libB.a
IMPORTED_LINK_INTERFACE_**LIBRARIES C D
)
which is read inside my CMakeLists.txt with:
import(MyFile.cmake)
add_library(A foo.cc)
add_executable(bar bar.cc)
target_link_libraries(bar A B)
Here's the point. My library B depends on C, which I checked out with A
and so is kind of local to my build, in fact I have:
add_directory(A)
add_directory(C)
in my main CMakeLists.txt, but when I build the packages I always get:
No rule to make target `../../lib/libC.a', needed by `../../bin/bar'.
Stop.
Looking into the link.txt file generated by cmake, I see that the
dependencies are correct, that is the command is:
g++ -o bar ../../lib/libA.a /path/to/external/lib/libB.a
../../lib/libC.a /path/to/external/lib/libD.a
So this is not a problem of how I declare my dependencies among packages,
rather something related to the way cmake deals with the targets. What
sounds strange to me is that package C is perfectly known to cmake, as I
put add_directory(C) to my CMakeLists.txt. In fact libC.a is built, but
always *after* bar, like cmake were not aware that C, on which bar depends,
must be built before it.
I suspect that cmake thinks that, since B is external, it's up to the
user to provide a rule to force the build of dependencies. Put it another
way: if you have packages A and C locally and B is an external but
depends on C, then cmake has no means to write the target libC.a that
triggers the build of C before linking A with B.
Is there a way, if any, to instruct cmake to write the targets so that the
dependencies chain is preserved and if an external depends on an internal,
the internal is built before the link stage?
Thanks in advance.
Marco
--
Marco Corvo
SuperB Experiment
CNRS - Orsay
c/o INFN Padova
--
Powered by www.kitware.com
Visit other Kitware open-source projects at http://www.kitware.com/**
opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/**listinfo/cmakehttp://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
