Linking to lib is using -lmylib instead of ws/install/pkg/lib/mylib.so

edit

Let's take a step back.

Should you be wrapping a system dependency in a ROS package? If it's not a ROS package, don't try to make it one.

Do you have a specific reason for not just keeping it a plain cmake build type?

Out of nowhere the -lmylib is stated. I just could not figure it out where to find a proper way to alter that input.

In general, when you start asking yourself "how do I manually fiddle with this automatically generated artefact?" it may be a sign something is not right, or should not be used in that way.

Hey there,

That‘s a really good question. I somehow expected that I only can use a ros-packaged library. Are there any hints to just use the cmake way? I sadly am a absolut noob regarding CMakeList..

In the end I want to use that library in a ROS2 package. But I do not need to make that lib a ros library. I just thought I had to or otherwise find_package and all that is not gonna find it..

Thank you!

But of course, I would like to know what small little detail I‘m missing to make it right. If feels like I‘m just one step away.

Although the adapter Interface Export feels like it will haunt me in the next step.. 😅

Just wanted to have a nice way of watching a file directory with inotify..

No, you don't need to make everything "a ROS lib".

In the end, both Catkin and Ament are all "just CMake wrappers/macros", so if you can find_package(..) your library / project from a plain CMakeLists.txt, you can use it in a ROS project (ie: a CMakeLists.txt with ROS specific content).

There are quite a few Q&As here on ROS Answers discussing how to "use external libraries with ROS" (or similar phrasing). ROS 2 has not changed much there. It's still all CMake (perhaps even more so).

I sadly am a absolut noob regarding CMakeList..

you may want to follow some tutorials on CMake first then. Don't mix in ROS / ROS 2. It will only complicate things.

I somehow found my root problem:

target_link_libraries(${PROJECT_NAME}_node ${lib_foo_LIBRARIES})

As there is only a name of the shared library given by _LIBRARIES (i.e. mylib), target_link_libraries interprets that sort of correctly like a installed system library. See explaination from documentation:

If an imported library has the IMPORTED_NO_SONAME target property set, CMake may ask the linker to search for the library instead of using the full path (e.g. /usr/lib/libfoo.so becomes -lfoo).

So with this tweak, I got my package to successfully link my .so: target_link_libraries(${executable_name} "${inotify-cpp_LIBRARY_DIRS}/lib${inotify-cpp_LIBRARIES}.so")

But I still wonder what causes my library to set the IMPORTED_NO_SONAME and where I need to include this..

Hmm..

Actually I found in myLibTargets-noconfig.cmake this:

# Import target "inotify-cpp::inotify-cpp-shared" for configuration ""
set_property(TARGET inotify-cpp::inotify-cpp-shared APPEND PROPERTY IMPORTED_CONFIGURATIONS NOCONFIG)
set_target_properties(inotify-cpp::inotify-cpp-shared PROPERTIES
  IMPORTED_LOCATION_NOCONFIG "${_IMPORT_PREFIX}/lib/libinotify-cpp.so.0.2.0"
  IMPORTED_SONAME_NOCONFIG "libinotify-cpp.so.0.2.0"
  )

So I'm asking myself now what I need to do to load the generated Targets-noconfig.cmake to properly load into my CMakeList.txt so that I can again use the lib-name. I'm using inotify-cpp in the linker script. But this seems to be a little bit more advanced inotify-cpp::inotify-cpp-shared, some sort of namespace..