Hey all, Since I did not receive a reply to my previous mail, I decided to write a minimal example explaining my problem, where I kept al the names as I used in my previous mails. I hope that after seeing my example, someone can explain me what I am doing wrong here. I included a script that reproduces the problem.
Cheers, Sven On 06/10/2016 01:34 PM, Sven Baars wrote: > Hey Chuck, > > In ATargets.cmake it says > > add_library(a SHARED IMPORTED) > > and in BTargets.cmake it says > > add_library(b SHARED IMPORTED) > > However, if I build C it will say > > /usr/bin/ld: cannot find -la > > when I do > > find_package(B) > target_link_libraries(c b) > add_executable(main main.cpp) > target_link_libraries(main c) > > This, I think, because the 'b' target depends on 'a' but doesn't know > where 'a' is located, because this is not described in BTargets.cmake. > > Sven > > On 06/08/2016 06:07 PM, Chuck Atkins wrote: >> If the projects are each providing their own Config.cmake file then >> you probably will want to use those instead of Find modules. Instead >> of using the Foo_Bar_LIBRARIES variable though, try using the actual >> imported targets from the config files. Those should have the >> appropriate dependency information. If you're not sure what they are >> you should be able to dig through the provided Config.cmake and >> Targets.cmake files for FooBar and see which targets are created bu >> "add_library(FooBar::Foo ... IMPORTED)". >> >> - Chuck >> >> On Wed, Jun 8, 2016 at 11:31 AM, Sven Baars <s.ba...@rug.nl >> <mailto:s.ba...@rug.nl>> wrote: >> >> In my case all projects provide their own FooBarConfig.cmake, but >> not a FindFooBar.cmake. For this reason I wanted to use those, >> because I thought it saves me the effort of writing a lot of >> FindFooBar.cmake files, and it also seemed like the right way to >> do it, because it provides things like FooBar_LIBRARIES, which is >> what I need. The reason I said that I create my own >> FooBarConfig.cmake, is because I want to use CMake properly in my >> own project, so I also want to provide a FoorBarConfig.cmake file >> for my users. So even if the projects I use don't do everything >> properly, I still want to do it properly myself. The problem in >> this case is that I'm not sure what the proper way is. If the >> FoorBarConfig.cmake file is not enough to handle the dependencies >> I encounter, should I provide a FindFooBar.cmake file or >> something, instead of just the FooBarConfig.cmake? And meanwhile >> also write a FindFooBar.cmake file for all my dependencies? >> >> Another reason why this seems odd to me, is because if N >> different projects use FooBar, then also possibly N different >> versions of FindFooBar.cmake are created by all the different >> projects (I have actually already seen this a lot). That is the >> case, because the FindFooBar.cmake file is not provided by the >> FooBar project, unlike the FooBarConfig.cmake. >> >> Cheers, >> Sven >> >> >> On 06/08/2016 03:11 PM, Chuck Atkins wrote: >>> The FooBarConfig.cmake is something that should be generated by >>> FooBar's build. The reason you don't get absolute paths for >>> the "libraries" from a package config file is that they're not >>> actually libraries but imported targets. The imported target >>> let's you treat "foo" as though it were a library built by your >>> project. It then has the appropriate target properties set on >>> it ti define the full path to it's library, etc. That being >>> said, if you're manually creating the FooBarConfig.cmake that's >>> not really the right approach. If the FooBar buil;d doesn't >>> actually generate it's own FooBarConfig.cmake file then you'll >>> want to create you're own FindFooBar.cmake. A bare bones find >>> module that creates an imported target would look something like >>> this: >>> >>> if(NOT FooBar_FOUND AND NOT TARGET FooBar::FooBar) >>> find_path(FooBar_INCLUDE_DIR FooBar.h) >>> find_library(FooBar_LIBRARY FooBar) >>> >>> include(FindPackageHandleStandardArgs) >>> find_package_handle_standard_args(FooBar >>> FOUND_VAR FooBar_FOUND >>> REQUIRED_VARS FooBar_INCLUDE_DIR FooBar_LIBRARY >>> ) >>> endif() >>> >>> if(FooBar_FOUND AND NOT TARGET FooBar::FooBar) >>> add_library(FooBar::FooBar UNKNOWN IMPORTED) >>> set_target_properties(FooBar::FooBar PROPERTIES >>> IMPORTED_LOCATION ${FooBar_LIBRARY} >>> INTERFACE_INCLUDE_DIRECTORIES ${FooBar_INCLUDE_DIR} >>> ) >>> endif() >>> >>> Then in your project you can use: >>> >>> find_package(FooBar) >>> add_library(MyLib supercoolfiles.cxx) >>> target_libkLibraries(MyLib FooBar::FooBar) >>> >>> Where this starts to get really helpful in your situation is if >>> you have an imported target for A, B, and C, then you can create >>> the appropriate dependencies. Say, for example, you have a >>> FindA.cmake that follows the pattern above and generates an A::A >>> target. Then in your FindB.cmake you can have: >>> >>> if(NOT B_FOUND AND NOT TARGET B::B) >>> find_path(B_INCLUDE_DIR B.h) >>> find_library(B_LIBRARY B) >>> >>> include(FindPackageHandleStandardArgs) >>> find_package_handle_standard_args(B >>> FOUND_VAR B_FOUND >>> REQUIRED_VARS B_INCLUDE_DIR B_LIBRARY >>> ) >>> >>> * find_package(A QUIET) >>> if(A_FOUND) >>> set(B_Extra_Deps A::A) >>> endif()* >>> endif() >>> >>> if(B_FOUND AND NOT TARGET B::B) >>> add_library(B::B UNKNOWN IMPORTED) >>> set_target_properties(B::B PROPERTIES >>> IMPORTED_LOCATION ${B_LIBRARY} >>> INTERFACE_INCLUDE_DIRECTORIES ${B_INCLUDE_DIR} >>> ) >>> * if(B_Extra_Deps) >>> set_target_properties(B::B PROPERTIES >>> INTERFACE_LINK_LIBRARIES ${B_Extra_Deps} >>> ) >>> endif()* >>> endif() >>> >>> and similarly for FindC.cmake. Since A::A, B::B, and C::C are >>> actual proper CMake targets and not just library files then they >>> carry with them associated target dependency information. In >>> CMake vernacular we refer this as "target usage requirements" >>> since the target caries with it all the necessary information >>> for something to actually use it, whether that's just extra link >>> libraries or also extra include directories and compile >>> definitions needed. The Package::Target naming convention is >>> the idea that each package has it's own namespace where you may >>> define multiple targets. >> >> >
cmake-example.tar.gz
Description: application/gzip
-- 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://public.kitware.com/mailman/listinfo/cmake