Some cmake improvements

[simogasp]

Hi Laurent,

this PR add some improvements (I hope..) to the cmake building system, but it does not break any compatibility with the previous version (ie building, installation and use as 3rd party is the same as before, hopefully more robust). In particular:

• the minimal version for cmake is raised to 3.1.3 instead of 3.1.0 because of a cmake bug in managing CMAKE_CXX_STANDARD 11 properties (here the ref to the bug).
• There is now a template for the opengvConfig.cmake, which allows to automagically load the proper opengvTargets[Release, Debug].cmake according to the build configuration. This way, e.g. one can install all the library configurations in the same place and the host will grab the needed one.
• It uses target_include_directories(), which is preferable over include_directories() for properly propagating the includes when the lib is used as 3rd party.
• There are some other minor improvements that better exploits the features of cmake > 3.0, eg the version is declared directly in project(), which automatically sets the various PROJECT_VERSION_MAJOR etc.. variables (see here for reference).
• It also brings back to life and updates the .travis.yml for continuous integration, everything builds fine now, both with clang 3.5 and gcc 4.8.4. I had to use a dirty hack in FindNumpy as apparently the executable tested inside the function has no visibility over the system modules (?). Maybe @paulinus can find a better solution? :-) See here for an example of working building on travis.

I hope it helps.

Cheers

Simone

[NikolausDemmel]

Do you happen to know what would be required to make the opengvConfig also work in the build directory? I.e. such that in a project where I want to use a specific local build of opengv I could find_package after setting opengv_DIR to the build directory?

I tried with your changes, but looks like while opengvConfig.cmake and opengvConfigVersion.cmake are now generated in the build directory, they are not useable without installing.

CMake Error at /Users/demmeln/work/slam/opengv/build/opengvConfig.cmake:27 (include):
  include could not find load file:

    /Users/demmeln/work/slam/opengv/build/opengvTargets.cmake
Call Stack (most recent call first):
  CMakeLists.txt:6 (find_package)

-- Configuring incomplete, errors occurred!

Other libraries like ceres and Pangolin support this.

[simogasp]

that's true, opengvTargets.cmake is not generated for the build directory. You have two options: 1) try to add this before install(TARGETS opengv... (line 356)

export(TARGETS opengv FILE "${CMAKE_CURRENT_BINARY_DIR}/${targets_export_name}.cmake")

that should generate the missing file for the build directory. (sorry no time to test it...)

2) you can install locally: run cmake with the option -DCMAKE_INSTALL_PREFIX:PATH=/Users/demmeln/work/slam/opengv/build/install (or whichever other path you want) and then make install. That will install the lib in a non-system directory and you'ill be able to use it with opengv_DIR

Hope it helps

S.

[NikolausDemmel]

Thanks for the quick reply.

Option 1 works for me, very nice! It would probably be good to include this in this PR, but no rush.

Option 2 would also work, but has the downside that when you use this for development and do some changes in OpenGV headers, you don't notice in git, since they are done in the install folder.

[simogasp]

Option 2 would also work, but has the downside that when you use this for development and do some changes in OpenGV headers, you don't notice in git, since they are done in the install folder.

Well, actually that's a very bad idea! :-) You should never change the headers in the installed part, you should make your changes in the repository as you usually do and just use make install instead of the usual make.

I'll add it to the PR soon, hoping it will be merged one day...

[NikolausDemmel]

Well, actually that's a very bad idea! :-) You should never change the headers in the installed part, you should make your changes in the repository as you usually do and just use make install instead of the usual make.

Yes exactly, but this is what happens if you use option 2) and are not super careful and your IDE opens the installed headers, since it doesn't know about the source directory.

[NikolausDemmel]

I'll add it to the PR soon, hoping it will be merged one day...

+1 from me, works for my use case nicely (with the additional line).