Fix build of downstream packages.

[peci1]

Fixed libpointmatcher_ros build in catkin workspace.

[jlblancoc]

LGTM. Thanks! 👍

[peci1]

The pkgconfig files are definitely still wrong as they have no way to expand the generator expressions. But I'll leave that to others as my interest is in the CMake config files.

Could you please require that contributors (or Jenkins) do a more complex test than "hey, this library builds alone" before doing such substantial changes to the project?

[YoshuaNava]

Could you please require that contributors (or Jenkins) do a more complex test than "hey, this library builds alone" before doing such substantial changes to the project?

If I remember well, the Jenkins pipeline passed for the original PR. Another user also tested and said that it solved the issues with libnabo.

Can you provide more info about your setup and how you tested it? Based on that feedback we could improve the tests.

[pomerlef]

@peci1 I agree that those build modifications are annoying, but we don't do that really often. It's also rare that a library test for downstream dependencies, although I agree that libpointmatcher_ros is maintained by ourselves also.

[pomerlef]

@peci1 thanks for being quick to solve the dependency issues. We should converge soon ;)

[peci1]

If I remember well, the Jenkins pipeline passed for the original PR. Another user also tested and said that it solved the issues with libnabo.

Yes, but the author of the PR also said that he only tested in build-space. Testing install-space is what's probably missing.

It seems to me that a good way to test the integration would be to have some kind of integration builds which would build all the things down to e.g. ethzasl_icp_mapper (actually doing make install for each repo). This way, you could be sure that changes in the lower-level libraries do not break downstream (or at least some downstream :) ). However, I can imagine such build could also fail when downstream packages get problems, so it probably shouldn't be a hard requirement for accepting PRs to libnabo/pm... Or you could create dummy test packages which would just try to find libnabo/pm via CMake and via pkgconfig and link some super-simple programs utilizing these libraries (ideally requiring the transitive dependency on libnabo via pm).

[peci1]

Could you also have a look at https://github.com/ethz-asl/laser_slam/tree/master/sensor_drivers/velodyne_assembler ? I get the following error:

/usr/bin/ld: /media/data/subt/mapper/devel/lib/libpointmatcher.a(OctreeGrid.cpp.o): undefined reference to symbol 'pthread_create@@GLIBC_2.2.5'
/lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
tradr-laser-slam/sensor_drivers/velodyne_assembler/CMakeFiles/velodyne_assembler_node.dir/build.make:157: recipe for target '/media/data/subt/ws/devel/lib/velodyne_assembler/velodyne_assembler_node' failed
make[2]: *** [/media/data/subt/ws/devel/lib/velodyne_assembler/velodyne_assembler_node] Error 1
CMakeFiles/Makefile2:32852: recipe for target 'tradr-laser-slam/sensor_drivers/velodyne_assembler/CMakeFiles/velodyne_assembler_node.dir/all' failed
make[1]: *** [tradr-laser-slam/sensor_drivers/velodyne_assembler/CMakeFiles/velodyne_assembler_node.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

[YoshuaNava]

@peci1 The above issue has been pointed out before by other colleagues. The Octree Grid filter might be missing a pthread depend, which can be fixed easily by linking against pthread.

[peci1]

Okay. Is that something you're about to fix in libpm?

[YoshuaNava]

@peci1 I'll take a look during the day and tag you in the PR.

Out of curiosity: what is your build chain?

[peci1]

We use ROS melodic and build ethzasl_icp_mapper with catkin tools.

[YoshuaNava]

Additional questions:

• Which version of gcc/clang?
• Target platform x86?

Pull request: #417

[peci1]

gcc 7.5.0 (I think bionic default), building for amd64 (but soon we'll also need arm64)