tier4 / osqp_vendor

Vendor package for OSQP
Apache License 2.0
5 stars 5 forks source link

Exporting dependencies #2

Closed fred-apex-ai closed 4 years ago

fred-apex-ai commented 4 years ago

@esteve I tried to use the osqp_vendor package in osqp_interface. This a commit documenting things I tried. I failed. Can you please give me instructions on how to consume that vendor package?

When I print out all variables involving osqp_vendor, I get

-- _osqp_vendor_CONFIG_INCLUDED=TRUE
-- osqp_vendor_CONFIG=/home/frederik.beaujean/AutowareArchitectureProposal/install/osqp_vendor/share/osqp_vendor/cmake/osqp_vendorConfig.cmake
-- osqp_vendor_CONSIDERED_CONFIGS=/home/frederik.beaujean/AutowareArchitectureProposal/install/osqp_vendor/share/osqp_vendor/cmake/osqp_vendorConfig.cmake
-- osqp_vendor_CONSIDERED_VERSIONS=0.0.1
-- osqp_vendor_DEPENDENCIES=osqp
-- osqp_vendor_DIR=/home/frederik.beaujean/AutowareArchitectureProposal/install/osqp_vendor/share/osqp_vendor/cmake
-- osqp_vendor_FOUND=1
-- osqp_vendor_FOUND_AMENT_PACKAGE=TRUE
-- osqp_vendor_LIBRARIES=/home/frederik.beaujean/AutowareArchitectureProposal/install/osqp_vendor/lib/libosqp.so
-- osqp_vendor_RECURSIVE_DEPENDENCIES=osqp
-- osqp_vendor_TARGETS=osqp
-- osqp_vendor_VERSION=0.0.1
-- osqp_vendor_VERSION_COUNT=3
-- osqp_vendor_VERSION_MAJOR=0
-- osqp_vendor_VERSION_MINOR=0
-- osqp_vendor_VERSION_PATCH=1
-- osqp_vendor_VERSION_TWEAK=0

The issue

compilation error

VERBOSE=1 make -C build/osqp_interface/
...
[ 33%] Building CXX object CMakeFiles/osqp_interface.dir/src/osqp_interface.cpp.o
/usr/bin/c++  -DDEFAULT_RMW_IMPLEMENTATION=rmw_fastrtps_cpp -DSPDLOG_COMPILED_LIB -I/home/frederik.beaujean/AutowareArchitectureProposal/src/autoware/autoware.iv/common/math/osqp_interface/include -I/usr/include/eigen3 -isystem /opt/ros/foxy/include  -Ofast -std=gnu++14 -o CMakeFiles/osqp_interface.dir/src/osqp_interface.cpp.o -c /home/frederik.beaujean/AutowareArchitectureProposal/src/autoware/autoware.iv/common/math/osqp_interface/src/osqp_interface.cpp
/home/frederik.beaujean/AutowareArchitectureProposal/src/autoware/autoware.iv/common/math/osqp_interface/src/osqp_interface.cpp:22:10: fatal error: osqp.h: No such file or directory
   22 | #include "osqp.h"

the include directories are not defined

THere is no -I argument introducing the osqp source directory in the call to c++. And there is no osqp_vendor_* variable to cover that, so I can't even introduce it manually in my CMakeLists.txt

targets

Manually a target is added in osqp_vendor-extras.cmake so osqp_vendor_TARGETS=osqp but it's not a real target; i.e. I can't print out its properties, can't get its link or include directories etc. This blog post describes how to properly add properties to targets for downstream consumption. As far as I can tell, osqp_vendor falls short in most ways but I may be missing something because of the interaction with ament.

fred-apex-ai commented 4 years ago

@esteve I missed the fact that you pushed a commit to my branch and so I wasted quite some time experimenting around. Now I understand the scope of the vendor package, I need both

find_package(osqp_vendor REQUIRED)
find_package(osqp REQUIRED)

then it works. Sorry for the confusion. I still think that the build system and the cmake files aren't organized according to modern cmake best practices but let's ignore that for now

esteve commented 4 years ago

@fred-apex-ai

This blog post describes how to properly add properties to targets for downstream consumption.

Can you paste the link to the blog post you mention?

Manually a target is added in osqp_vendor-extras.cmake so osqp_vendor_TARGETS=osqp but it's not a real target; i.e. I can't print out its properties, can't get its link or include directories etc.

osqp is a real target exported by the osqp package (https://github.com/oxfordcontrol/osqp/blob/master/CMakeLists.txt#L284), osqp_vendor reexports that target to be used by downstream packages.

Sorry for the confusion. I still think that the build system and the cmake files aren't organized according to modern cmake best practices but let's ignore that for now

AFAIK, the modern approach to inter-package dependencies in CMake >= 3.0 (https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/) is to use targets instead of variables for include dirs, libraries, etc.

In any case, could you elaborate what you mean by modern CMake best practices? Thanks.

fred-apex-ai commented 4 years ago

@esteve Sorry if I caused you confusion, it spun off from my own confusion. Yes I forgot to add the link but you found it anyhow :) https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/ I meant that for modern cmake best practices

From what I could tell, but correct me if I'm wrong, ament_* things communicate information between packages via variables, not via targets, and targets aren't namespaced etc. But the issue is more me wanting to understand exactly what happens behind the scenes, nothing for you to fix. Now I looked further and saw that NAMESPACE is used in https://github.com/ament/ament_cmake/blob/933e2838c0404fd061479e0a826947dfc35e81de/ament_cmake_export_targets/cmake/ament_cmake_export_targets_package_hook.cmake#L31 but I'm not sure if this hook is called. How could I check the exported targets of a package that I import/depend on?

Manually a target is added in osqp_vendor-extras.cmake so osqp_vendor_TARGETS=osqp but it's not a real target; i.e. I can't print out its properties, can't get its link or include directories etc.

osqp is a real target exported by the osqp package (https://github.com/oxfordcontrol/osqp/blob/master/CMakeLists.txt#L284), osqp_vendor reexports that target to be used by downstream packages.

Yes, I saw that, too. My problem was that I hadn't it imported it properly, so the target didn't exist.