Closed git-user44 closed 2 years ago
That's intended, and expected behavior. The same technique was used in opencv, or in recent versions of ros2 packages.
The idea is to keep include files within a path that might not be included unintentionally. If we placed, say
mrpt/comms/CSerialPort.h
directly like /usr/include/mrpt/comms/CSerialPort.h
, user programs will always find the header even if they forget to add the corresponding dependency via cmake in their programs.
I hope this makes sense...
PS: you can always validate the installation by configuring and building (with cmake) this minimal mrpt program, which should work and use the installed headers and libraries.
Thanks for the reply. As I said I do not have a great knowledge of cmake.
It's a voyage of discovery this MRPT stuff, and at least I have learnt what CMAKE_TOOLCHAIN_FILE is used for
I am installing a build from source with the command
[mike@modron mrpt-2.4.8]$ cd build [mike@modron build]$ sudo cmake --install .
I assume this is correct and no other options are required.
The libraries all seem to go into /usr/lib64 (as expected) but the #include files seem to get an extended path, I assumed they should go into /usr/include/mrpt/... but they end up like ... well, let's try finding a couple.
[mike@modron mrpt-2.4.8]$ find /usr/include -name CMetricMapBuilder.h /usr/include/mrpt/slam/include/mrpt/slam/CMetricMapBuilder.h [mike@modron mrpt-2.4.8]$ find /usr/include -name CSerialPort.h /usr/include/mrpt/comms/include/mrpt/comms/CSerialPort.h
It seems there's an extra "include/mrpt/whatever" getting in the path name when the file is copied. Fairly convinced this is not right. I had bit of a look at the various cmake files , but my knowledge of cmake is limited and nothing leapt out at me.
This is not mission critical. I have a script that moves the files to (what I believe to be) the correct place.
FWIW: 2.4.9 does the same thing.