cmake export configuration

[sjulier]

g2o comes with a cmake script (FindG2O.cmake) which can be used by other applications to locate and build g2o. This uses the "Module" style of search, requires manually setting up and manual installation. However, cmake has a much more covenient "Config" style which is easier to set up and use (see https://cmake.org/cmake/help/v3.1/command/find_package.html).

I've created a new branch Export_cmake_Configuration which uses the "Config" style to create the g2o cmake configuration and automatically install it.

Usage is as follows. Suppose I have an application myApp which uses the g2o_cli library. The cmake file is:

cmake_minimum_required(VERSION 3.1)

find_package(g2o REQUIRED)
find_package(Eigen3 REQUIRED)

add_executable(myApp myApp.cpp)

target_link_libraries(myApp g2o::g2o_cli_library Eigen3::Eigen)

I have tested this for both the static and dynamic library build under OSX. I don't have any other platforms I can test on right now. I would be interested to hear questions / comments.

Cheers,

Simon

[sergiud]

Really nice. I would only prefer writing g2o::core instead of g2o::g2o_core. No need to duplicate the namespace.

[sjulier]

Thanks. Actually you should be able to do g2o::stuff, g2o::core, etc. The g2o_ prefix arises from the name of the target (g2o_cli_library).

This probably wasn't the best illustrative case. However, it' a test case I've been using because I can check if a library pulls in other dependent libraries properly.

[cyberguy42]

This is great! I am on Ubuntu 16.04 using a from-source build of ROS Kinetic, and I was struggling to get teb_local_planner to link against g2o. I checked out your branch, and most of the linking errors went away. I am still getting undefined references for the following functions:

g2o::csparse_extension::cs_chol_workspace(cs_di_sparse const*, cs_di_symbolic const*, int*, double*)'
g2o::csparse_extension::cs_cholsolsymb(cs_di_sparse const*, double*, cs_di_symbolic const*, double*, int*)
g2o::csparse_extension::writeCs2Octave(char const*, cs_di_sparse const*, bool)

Are you able to link against the csparse_extension library?

All of my ROS packages and source dependencies are in a catkin workspace, including teb_local_planner and libg2o. I build the workspace using catkin tools.

Edit: Some further information: I confirmed that libg2o_csparse_extension.so is in my workspace's lib folder. Furthermore nm -D libg2o_csparse_extension.so confirms that all 3 functions are in the library.

[sjulier]

Hmm... I haven't seen this particular issue, but I'm running on OSX and things like library linker order issues don't matter.

Could you provide a bit more information on what the setup is? Can you build with "make VERBOSE=1" to confirm what libraries are being imported, and the order in which they are imported?

Cheers,

Simon

[cyberguy42]

These are the g2o libraries that are being imported (where {lib} represents the full path to my workspace lib directory):

{lib}/libg2o_csparse_extension.so
{lib}/libg2o_core.so
{lib}/libg2o_stuff.so 
{lib}/libg2o_types_slam2d.so 
{lib}/libg2o_types_slam3d.so 
{lib}/libg2o_solver_cholmod.so 
{lib}/libg2o_solver_pcg.so 
{lib}/libg2o_solver_csparse.so 
{lib}/libg2o_incremental.so

So it looks like the library is being imported. Does it matter that it is the first (of the g2o libraries)?

[sjulier]

It matters for static libraries. It might matter for shared objects:

https://stackoverflow.com/questions/45135/why-does-the-order-in-which-libraries-are-linked-sometimes-cause-errors-in-gcc

Do you know if the --as-needed flag is set?

Cheers,

Simon

[cyberguy42]

No --as-needed flag is set.

[cyberguy42]

Please ignore the errors I reported earlier, it turns out they came from mistakes on my end (not cleaning my build space after switching branches, incompatibilities between the versions of the packages, etc).

[sjulier]

Ah - thanks for letting me know. Does it all link okay?

[cyberguy42]

Sorry, didn't see your comment earlier. I took a break from trying to link it to clear my head, but will make another attempt. I'll let you know the results.

[cyberguy42]

The good news is that teb_local_planner is linking against libg2o properly now. The bad news is that I can't confirm whether your changes work on Ubuntu or not since I am using the branch of g2o provided by ROS. It's the same version I was originally using, so I'm not sure why it works now. Sorry about the false alarm.

[FlorianFranzen]

@sjulier Did you ever open a pull request to merge your changes into upstream? I would welcome your additions as well.

[majorx234]

one suggestion: could we add somethink like this: SET(G2O_LIBRARIES ${G2O_STUFF_LIBRARY} ${G2O_CORE_LIBRARY} ${G2O_SOLVER_CHOLMOD} ${G2O_SOLVER_CSPARSE} ${G2O_SOLVER_DENSE} ${G2O_SOLVER_PCG} ${G2O_SOLVER_SLAM2D_LINEAR} ${G2O_SOLVER_STRUCTURE_ONLY} ${G2O_SOLVER_EIGEN} ${G2O_SOLVER_CSPARSE} ${G2O_SOLVER_CSPARSE_EXTENSION})

Me as user don't want to know all internal library stuff. It's easier to have just an env-variable for this. so i just need to add in my program's CMakeLists.txt: target_link_libraries(myApp ${G2O_LIBRARIES})