jrl-umi3218/jrl-cmakemodules

CMake utility toolbox

Shared CMake submodule

This repository is meant to be used as a submodule for any project from CNRS LAAS/HPP or JRL.

It factorizes CMake mechanisms to provide a uniform look'n feel for all packages.

Please see the documentation on the wiki for more information.

You can also checkout the more complete documentation of the modules.

Supported CMake versions

We currently support CMake >= 3.10

pre-commit

This project use pre-commit and pre-commit.ci.

You can get a nice documentation directly on those 2 projects, but here is a quickstart:

# install pre-commit:
python -m pip install pre-commit

# run all hooks on all files:
pre-commit run -a

# run automatically the hooks on the added / modified files, when you try to commit:
pre-commit install

jrl-cmakemodules's Issues

IF($ENV{PATH}) not suitable on win32 systems

There is a compilation issue of logging.cmake at lines 86
IF($ENV{PATH})
and 93
IF($ENV{PKG_CONFIG_PATH})

The issue is that in win32 systems, these variables have the following syntax:
c:/first/path;c:/second/path
And the semi-colon makes the IF crash.

If the aim of the tests is only to check the existence of the variables, is it possible to add quotes around them ( ie check "$ENV{PATH}" instead of $ENV{PATH} ), which would correct the issue?

Fallback to MathJax doc if LaTeX/dvips are not available

Right now, this is solely controlled by the user-defined variable.

There is also a dependency on perl, but I am not sure what uses it. Is this still required?

Compilation Check of Eigen Version

I started getting runtime crashes without any other indications that were caused by my eigen version changing while Tasks, rbdyn, sva, etc were not recompiled. Ceres has a mechanism to prevent this I think would be worthwhile to add here and to the appropriate libraries.

• The error ceres reports in CeresConfig.cmake
• The configure_file call to set the appropriate variables

ImportError: cannot import name ... on Ubuntu 12.04. Linking issue due to --as-needed flag

Hello

I'm trying to run the stack of tasks on ubuntu 12.04, using only the command line (or the scripts with python -i)
I am encountering some issues when importing the symbols (from any library)

from robot_simu import RobotSimu
ImportError: cannot import name RobotSimu

And this error occur for any symbol of any library.

Note that the command

From ... import *

does not crash but it does not import anything either (...)

By running the command
ldd /wrap.so
I obtain two different results whether I compile on Ubuntu 12.04

 ldd dynamic_graph/tracer/wrap.so 
    linux-vdso.so.1 =>  (0x00007fff4cb43000)
    libpython2.7.so.1.0 => /usr/lib/libpython2.7.so.1.0 (0x00007f1d95fe2000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1d95c23000)
    libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f1d959c6000)
    libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f1d955fe000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f1d953e7000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1d951c9000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1d94fc5000)
    libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f1d94dc2000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1d94ac5000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1d948af000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f1d96709000)

or on ubuntu 10.04

ldd dynamic_graph/tracer/wrap.so 
    linux-gate.so.1 =>  (0x00b28000)
>>  tracer.so
    libpython2.6.so.1.0 => /usr/lib/libpython2.6.so.1.0 (0x00110000)
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x006f2000)
    libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x00364000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x008ff000)
    libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x0091e000)
    libdynamic-graph.so.2.5.1-19-gcfdc-dirty
    libboost_filesystem.so.1.40.0 => /usr/lib/libboost_filesystem.so.1.40.0 (0x006c2000)
    libboost_system.so.1.40.0 => /usr/lib/libboost_system.so.1.40.0 (0x0038a000)
    libboost_thread.so.1.40.0 => /usr/lib/libboost_thread.so.1.40.0 (0x0038f000)
    libboost_program_options.so.1.40.0 => /usr/lib/libboost_program_options.so.1.40.0 (0x003a4000)
    libboost_unit_test_framework.so.1.40.0 => /usr/lib/libboost_unit_test_framework.so.1.40.0 (0x00832000)
    liblapack.so.3gf => /usr/lib/liblapack.so.3gf (0x00c86000)
    libblas.so.3gf => /usr/lib/libblas.so.3gf (0x003ec000)
    libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x00469000)
    libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x0046d000)
    libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0x004d6000)
    libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0x0bd0f000)
    libz.so.1 => /lib/libz.so.1 (0x00486000)
    libutil.so.1 => /lib/tls/i686/cmov/libutil.so.1 (0x00bae000)
    /lib/ld-linux.so.2 (0x004b9000)
    librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0x0068a000)
    libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0x0051f000)

Since the library tracer.so is only linked on ubuntu 10.04, I think this error is really similar to the one detailed by Sebastien there:
#12,
ie that the flag --as-needed prevents the library wrap.so from linking with the adequate library.

Thus, I have canceled this flag by adding the following line on python.cmake

TARGET_LINK_LIBRARIES(${PYTHON_MODULE} "-Wl,--no-as-needed")

in the branch topic/ubuntu12_04

This cancels the default flag "--as-needed" that is added on ubuntu 12.04, for each python library wrap.so

I have tested it on ubuntu 10.04 and ubuntu 12.04, and it works well.
If you're okay with, I'll push it on jrl-cmakemodules and synchronize some repo.

François

Note: I've tried with other flags (such as -u), but it's the only one that worked.
http://stackoverflow.com/questions/11917014/enforce-linking-with-a-shared-library-with-wl-as-needed-when-only-templates

Catkin issue with CMAKE_SOURCE_DIR

There is a cmake issue when using the catkin with the jrl-cmakemodules.
This issue is due to the fact that the value CMAKE_SOURCE_DIR is defined at the creation of the catkin workspace.
It is hence defined in ~/${CATKIN_WORKSPACE}/build/config.log
and corresponds to ${CATKIN_WORKSPACE}/src

This prevents the correct execution of the routine based on this value.
In the case of laas/romeo#6
the git describe function fails because it is not run in the proper repository.

A solution to solve this issue is to use CMAKE_CURRENT_SOURCE_DIR instead.

Double installation of the headers

Hello

I noticed that during the installation of a project, there is a double installation of the headers of the header group ${PROJECT_NAME}_HEADERS: one is realized by header.cmake, the other one by install-data.cmake

Even though it is not really an issue, which one should be destroyed ?

François

Version number is not computed if git is not found

This is half a problem of jrl-cmakemodules, half a problem of the way we write our CMakeLists.

As of now, the version number of a library (that will be used to generate the .pc) can be computed solely based on git tags. This gives a rich version number which includes the exact commit used for generating the library.
Because we rely on this behavior, we (almost?) never set PROJECT_VERSION in the CMakeLists.

As a consequence, if git is not found (and there are several user scenarios in which this can happen), the version will be set to UNKNOWN-dirty. This is problematic for subsequent use of a library, when a minimum version number is required.

One solution would be to simply set PROJECT_VERSION in the library's CMakeLists, but, due to the actual logic in base.cmake and version.cmake, it will override the richer git-computed version number, changing the actual number whether git is found or not.
The alternative is to change this logic to have the git-computed version take precedence over PROJECT_VERSION, and fallback to PROJECT_VERSION only when git is not found. Possibly, we can add an error when neither git nor PROJECT_VERSION is found to enforce the generation of a number.

If nobody objects, I'll make the changes of the alternative.

License switch to BSD-clause 2

Dear all,
Would you mind that we switch the license to BSD-clause 2 which is much more business friendly.

Compilation flags from pkg-config are quoted with spaces

I was building a project, and decided to update the jrl-cmakemodules. Immediately, the build broke in Release mode, but not in Debug mode.

The reason is that in one of the depending .pc we have this line:

Cflags:  -I${includedir} -I/usr/include -DBOOST_SYSTEM_NO_DEPRECATED

Then, the generated compile command when using the Release mode contains:

-isystem /usr/include/libdrm    " -DBOOST_SYSTEM_NO_DEPRECATED"

Which obviously fails with:

clang: error: no such file or directory: ' -DBOOST_SYSTEM_NO_DEPRECATED'

While in Debug mode:

-isystem /usr/include/libdrm    "-DBOOST_SYSTEM_NO_DEPRECATED "

And this works.

This leads me to believe that cflags should not be enclosed in quotes, or trimmed beforehand. A simple fix is to remove this line (pkg-config.cmake:674):

STRING(REPLACE ";" " " CFLAGS "${CFLAGS}")

However, this operation is supposed to be necessary for "old" CMake, but I am running 2.8.12: is it really necessary?

Update to more recent CMake version

This is not of high priority but, for some of them, we regularly get warning messages. If relevant, I will try to update the list as I discover changes.

• the project version should be passed to macro project (from 3.0 I think).
• CMake targets of the form boost::python rather than providing the path.

Documentation cross-links does not work for more than one package registered in TAG_FILES

Cross-links does not work when more than one package is used in cross-links.

Problem with make uninstall

For some reason, running make uninstall generates the following error (with BUILD_DIR the build directory and HEADER_PATH the full path to the first header in the install manifest):
make[3]: Entering directory BUILD_DIR
/usr/bin/cmake -P BUILD_DIR/cmake/cmake_uninstall.cmake
-- Uninstalling "HEADER_PATH"
CMake Error at cmake/cmake_uninstall.cmake:34 (MESSAGE):
Problem when removing
"HEADER_PATH"

The problem does not appear on branch topic/cmake-2.8.0 and is almost certainly due to the replacement of EXEC_PROGRAM by EXECUTE_PROCESS, but I do not know how to fix it.

Any ideas?

Provide a basic template project for jrl-cmakemodules

I haven't been able to find such an example, and some people interested in trying the jrl-cmakemodules were asking for one.

cc @Galdeano

Double installation of the headers

Hi

I discovered that there is a double installation of the headers ${PROJECT_NAME}_HEADERS in headers.cmake

The following lines can be found twice

  INSTALL(FILES ${${PROJECT_NAME}_HEADERS}
    DESTINATION "include/${HEADER_DIR}"
    PERMISSIONS OWNER_READ GROUP_READ WORLD_READ OWNER_WRITE
    )

First in the macro _SETUP_PROJECT_HEADER, then in the macro _SETUP_PROJECT_HEADER_FINALIZE.

Could we remove the occurence that is in _SETUP_PROJECT_HEADER ? It would allow adding headers after calling the macro SETUP_PROJECT

Francois

boost_python library could not be found on Ubuntu 19.04

I get the following error from CMake trying to find boost python libraries:

CMake Warning at /usr/share/cmake-3.13/Modules/FindBoost.cmake:1775 (message):
  No header defined for python-py37; skipping header check
Call Stack (most recent call first):
  cmake/boost.cmake:104 (FIND_PACKAGE)
  CMakeLists.txt:169 (SEARCH_FOR_BOOST)


CMake Error at /usr/share/cmake-3.13/Modules/FindBoost.cmake:2100 (message):
  Unable to find the requested Boost libraries.

  Boost version: 1.67.0

  Boost include path: /usr/include

  Could not find the following Boost libraries:

          boost_python-py37

  Some (but not all) of the required Boost libraries were found.  You may
  need to install these additional Boost libraries.  Alternatively, set
  BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT
  to the location of Boost.
Call Stack (most recent call first):
  cmake/boost.cmake:104 (FIND_PACKAGE)
  CMakeLists.txt:169 (SEARCH_FOR_BOOST)


CMake Error at cmake/boost.cmake:107 (MESSAGE):
  Failed to detect Boost with the following components:

Call Stack (most recent call first):
  CMakeLists.txt:169 (SEARCH_FOR_BOOST)

The library name on my system is boost_python37, not boost_python-py37.

Changing the lines

IF(APPLE OR NETBSD_FOUND OR ARCHLINUX_FOUND)
          SET(BOOST_PYTHON_COMPONENT "python${PYTHON_VERSION_MAJOR}${PYTHON_VERSION_MINOR}")
        ELSEIF(DEBIAN_FOUND)
          SET(BOOST_PYTHON_COMPONENT "python-py${PYTHON_VERSION_MAJOR}${PYTHON_VERSION_MINOR}")
        ELSE(APPLE OR NETBSD_FOUND OR ARCHLINUX_FOUND)
          SET(BOOST_PYTHON_COMPONENT "python${PYTHON_VERSION_MAJOR}")
        ENDIF(APPLE OR NETBSD_FOUND OR ARCHLINUX_FOUND)

to

IF(APPLE OR NETBSD_FOUND OR ARCHLINUX_FOUND OR DEBIAN_FOUND)
          SET(BOOST_PYTHON_COMPONENT "python${PYTHON_VERSION_MAJOR}${PYTHON_VERSION_MINOR}")
        ELSE(APPLE OR NETBSD_FOUND OR ARCHLINUX_FOUND)
          SET(BOOST_PYTHON_COMPONENT "python${PYTHON_VERSION_MAJOR}")
        ENDIF(APPLE OR NETBSD_FOUND OR ARCHLINUX_FOUND OR DEBIAN_FOUND)

in https://github.com/jrl-umi3218/jrl-cmakemodules/blob/master/boost.cmake#L73 fixes the problem for me.

Link error when using ROSPACK_USE_DEPENDENCY

Hello,

There seems to be a link error related to the order of the link flags on Ubuntu 12.04 - 64bit when using the macro ROSPACK_USE_DEPENDENCY.
As a result, packages using this method do not link correctly.

This error appears for the package https://github.com/sbarthelemy/metapod/tree/add_metapodfromurdf
See laas/metapod#44 for the issue declaration.
Since I think the following patch concerns all package using ros.cmale, I prefer starting the discussion here.

The link error appears whereas the link flags are present in the compilation line (but to not seem to be at the right place).
However, adding a TARGET_LINK_LIBRARY seems to do the trick though.

FOREACH(dep roscpp rosconsole urdf)
  ADD_ROSPACK_DEPENDENCY(${dep})
  ROSPACK_USE_DEPENDENCY(metapodfromurdf ${dep})
  TARGET_LINK_LIBRARIES(metapodfromurdf ${dep}) # resolve the issue
ENDFOREACH()

This correction patches the linkage for the specific package metapod, but I wonder if it wouldn't be better to correct all packages depending on ros by directly modifying the file jrl-cmake/ros.cmake
Indeed, this seems to be an issue similar to the one that occurred with the pkg-config dependencies.
In other words, similarly to these lines in the file cmake/pkg-config.cmake

  IF(UNIX AND NOT APPLE)
    TARGET_LINK_LIBRARIES(${TARGET} ${${PREFIX}_LDFLAGS})
    TARGET_LINK_LIBRARIES(${TARGET} ${${PREFIX}_LDFLAGS_OTHER})
  ENDIF(UNIX AND NOT APPLE)

I'd like to add in the cmake/ros.cmake file has the equivalent form, aka

  IF(UNIX AND NOT APPLE)
    TARGET_LINK_LIBRARIES(${TARGET} ${PKG})
  ENDIF(UNIX AND NOT APPLE)

Are you ok with that?

François

Update Wiki and/or provide useful readme

A list of the main features (e.g. Doxygen support) would be really helpful. Right now, people need to read the *.cmake files. This could be made available in the Wiki, or in the README.md (which would probably be smarter since this is bundled in the submodule).

CMAKE_CXX_FLAGS order

Is there a specific reason for the order in https://github.com/jrl-umi3218/jrl-cmakemodules/blob/master/compiler.cmake#L61:

SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${WARNING_CXX_FLAGS}")

Setting CMAKE_CXX_FLAGS in this order means when doing

cmake -DCMAKE_CXX_FLAGS="something"

some of the flags of command line can be overwritten by flags in variable WARNING_CXX_FLAGS. Is this a desired behaviour ? Is there a problem with the following reordering:

SET(CMAKE_CXX_FLAGS "${WARNING_CXX_FLAGS} ${CMAKE_CXX_FLAGS}")

?

Generate the Doxyfile.extra.in automatically if not available

99% of users probably don't change that file, and merely copy it from somewhere else blindly. If it's not present, the error may be off-puting for new users. It should probably be generated automatically if not available, and we would expect the developer to add it to the project (we could print messages until he/she does).

Directory structure not preserved when installing headers

Hi,

I have a question about the installation of the headers, about the following point mentioned in headers.cmake

2. The headers are installed in the prefix
#    in a way which preserves the directory structure.

As I understand it, this means that if I install the following headers

myproject/api.h
myproject/subfold1/ex1.h
myproject/subfold2/ex2.h

(where the variable ${${PROJECT_NAME}_HEADERS) is set to
myproject/api.h; myproject/subfold1/ex1.h; myproject/subfold2/ex2.h)
the result of the installation would be:

install_path/include/myproject/api.h
install_path/include/myproject/subfold1/ex1.h
install_path/include/myproject/subfold2/ex2.h

Though, all the headers are installed in the directory include/myproject, and the resulting structure is the following one

install_path/include/myproject/api.h
install_path/include/myproject/ex1.h
install_path/include/myproject/ex2.h

Is that the desired behavior?

Regards

Francois

[Cmake] Configure called for already existing __init__.py

Hi,

In https://github.com/jrl-umi3218/jrl-cmakemodules/blob/master/python.cmake#L161, the __init__.py are created for each python module of the calling project, along with some other operations.

A problem arises when the source and binary directory are the same (for example in robotpkg), because the __init__.py already exists and is overwritten.

For example, because of a recent change of the build directory of sot-core-v3 in robotpkg, https://github.com/stack-of-tasks/sot-core/blob/master/src/dynamic_graph/sot/core/__init__.py is overwritten before the installation, leading to many import error…

Should we modify python.cmake to call CONFIGURE only if no __init__.py exists in the directory or is it a feature and it is the sot's CMakeLists.txt (and maybe other projects) that should not have called this macro?

Scope of _PKG_CONFIG_* variables

In pkg-config.cmake, all the SET commands have a "local" scope. Thus, if you use any of these functions (e.g. PKG_CONFIG_APPEND_LIBS) in a subdirectory, they will not be taken into account.

Was this done on purpose or is this simply a mistake? Note that the fix is simple enough, since we just need to add PARENT_SCOPE:

SET(_PKG_CONFIG_LIBS "${_PKG_CONFIG_LIBS} ${LIBINCL_KW}${LIB}${LIB_EXT}" PARENT_SCOPE)

Allow package containing a dash in their name to install their includes directly into include/${PACKAGE_NAME}

Currently, the behavior is to cut along the first dash and install in a subdirectory.
For instance x-y will install into: include/x/y.

Add a flag which allow to disable this behavior (for instance dynamic-graph needs it).

Call to post-project.cmake not working

Dear @gergondet and @jmirabel,

I'm currently passing Pinocchio to the new ordering of files (see stack-of-tasks/pinocchio#907). But it appaers that the call to post-project.cmake does not work performed after call to PROJECT(...) thanks to

jrl-cmakemodules/base.cmake

Line 150 in 0d3bc41

SET(CMAKE_PROJECT_${PROJECT_NAME}_INCLUDE "${CMAKE_CURRENT_LIST_DIR}/post-project.cmake")

.
Have you encountered similar bahavior on your respective sides?

Best,

Justin

Pollution caused by old library versions

As of now, make generates libraries called
lib<libname.so>.<git tag>-<?>-<commit hash>[-dirty]
and then creates a symlink <libname.so> to the newly-built library version (if there are no git tags, the name is <libname.so>.UNKNOWN).
This happens in the build directory.
Similarly, when doing make install, lib<libname.so>.<git tag>-<?>-<commit hash>[-dirty] is copied to the install directory and a symlink to it also installed/updated.

However, the old library versions are not deleted. Neither in the build directory when doing make, nor in the install directory when doing make install.

I don't know if this was intentional, but I think it does not work well. This causes a bunch of spurious files to just remain there and waste space (and screen space when doing ls). The amount of files can be considerate when doing development, since a new library is installed with basically every new commit.

make uninstall won't work either, because it will only remove the things which where installed with the last installation, not the old versions. make clean won't work either.

I believe that, when installing a new version, the old one should be removed.

Handling frameworks in OSX

OSX system may use frameworks instead of classic link unix flags in order to define the library a program has to link with.
This particular flag, that can be the result of a 'find_library' command, cannot be used directly as a link flag. As a result, the flag given in the .pc file is wrong:

Libs: /Path/lib.framework

while the correct version should be:

Libs -F Path -framework lib

As a result, it is not possible to use the command

 SET_TARGET_PROPERTIES(${TARGET}
    PROPERTIES COMPILE_FLAGS "${CFLAGS}" LINK_FLAGS "${LDFLAGS}")

anymore, since "/Path/lib.framework" is not a correct link flag.
Indeed, libraries loading this .pc will use the wrong flag

 -l/Path/lib.framework 

A solution to get round this difficulty is to use the command "target_link_library" instead, that enables avoiding this issue by realizing automatically the conversion.
Yet, this solution would only work for projects that use cmake: projects that only work with .pc files will not link correctly.
Hence, another solution is implemented in the topic/mac branch, that consists in verifying whether the flag is a framework or not, and correct the flag in this case.

NO_INCLUDE_SYSTEM not working (related to #195)

Wrt to Issue #195 the option NO_INCLUDE_SYSTEM is not taken into account.
The rational is the following:
The test in

jrl-cmakemodules/pkg-config.cmake

Line 779 in 0fb087e

IF(NOT NO_INCLUDE_SYSTEM)

is always true. Indeed it is testing if the variable NO_INCLUDE_SYSTEM exists or not (or if it is true or not). However as mentionned in cmake documentation macros arguments are not variables, but are used as string substitution. It should be replaced by ${NO_INCLUDE_SYSTEM}.
A PR fixing this will follow.

Catkin and distribution targets

Hi all,

I'd like to discuss an issue (and ideally a solution to that issue) that I encountered while working with several projects that use jrl-cmakemodules (and more specifically the SETUP_PROJECT macro) and trying to build them in a catkin environment.

When calling the SETUP_PROJECT() macro, a bunch of other macros are called, in particular, the _SETUP_PROJECT_DIST(), DISTCHECK_SETUP() and RELEASE_SETUP() macros. These macros create targets that are most useful for packaging purposes (i.e. dist* targets and release target).

Now, the catch is that if you have multiple projects within your catkin workspace that use this macro then your build will fail at the configuration step when invoking catkin_make because it's trying to create multiple targets that share the same name which is illegal.

One work-around is to use catkin_make_isolated (see http://www.ros.org/reps/rep-0134.html). Using the appropriate option it can be invoked in a way that the output mimics the results of catkin_make but the build still occur in an isolated way for each package. However, it would be nice to be able to invoke catkin_make directly without worries.

I see two possible solutions to this problem but there may be more (and better):

1. Change the dist* and release target names to something that depends on the project name (e.g. release-${PROJECT_NAME}). This requires very little effort but will break every scripts that are used to generate packages (e.g. jrl-umi3218/jrl-travis)
2. Don't generate these targets unless explicitly made to. This way, we require an additional arguments to have these targets generated. This makes the transition much easier for scripts that package the software (i.e. just use an additional argument when invoking cmake)

Any other solution that does not break anything would be most welcome. Alternatively it might just not make much sense to keep using SETUP_PROJECT within a catkin project.

A few more notes on the matter:

• afaik, it's not possible to redefine an existing target or even test for its existence
• it is also not possible to ignore those errors and continue onto the Makefile generation by cmake

Best,

Python version "mismatch" on Ubuntu 18.04

On a stock Ubuntu 18.04:

CMake Error at cmake/python.cmake:66 (MESSAGE):
  Python interpreter and libraries are in different version

With #178 for diagnosis I get:

-- PythonInterp: /usr/bin/python
-- PythonLibraries: /usr/lib/x86_64-linux-gnu/libpython2.7.so
CMake Error at cmake/python.cmake:66 (MESSAGE):
  Python interpreter and libraries are in different version: 2.7.15 vs
  2.7.15rc1
Call Stack (most recent call first):
  CMakeLists.txt:140 (FINDPYTHON)

This seems to match the Ubuntu Bionic stock Python: https://packages.ubuntu.com/bionic/python

Is there an easy workaround? The check (via string instead of version) seems a bit simplistic.

[CMake] Installing .pyc files

Hi,

In https://github.com/jrl-umi3218/jrl-cmakemodules/blob/master/python.cmake#L274 we try to install .pyc files.

First of all, I don't understand why.
Does someone have an explanation ?

Then, in python 3.2+, PEP 3147 states that compiled files are no more $filename.pyc, but __pycache__/$filename.<magic>.pyc with <magic> something like cpython-35, so cmake will not find $filename.pyc

This issue follows stack-of-tasks/pinocchio#464

Additional pkg-config variables are not detected properly.

License information

Is it possible to know under what license jrl-cmakemodules is released?

Could you add to the sources the COPYING or LICENSE file according to the license you choose?

Thx,

doxygen.cmake computes a wrong "make" program

doxygen.cmake:44 says: IF(UNIX) SET(MAKE make) etc.

This is wrong for at least two reasons:

• this relies on the user PATH having a "make" program
• this does not take into account user preferences (typically gmake vs. native make tool).

cmake has a CMAKE_MAKE_PROGRAM variable which already holds the correct program.
http://www.cmake.org/cmake/help/git-master/variable/CMAKE_MAKE_PROGRAM.html
(note that man cmake incorrectly documents it, but after testing it appears that this seems actually the right variable to use ... yay ;)

I would suggest the following patch (sorry, I cannot find a way to include it as an attachment...). This would help me fixing that kind of issue:
http://robotpkg.openrobots.org/rbulk/robotpkg/interfaces/abstract-robot-dynamics/abstract-robot-dynamics-1.20r1/NetBSD-6.1.1-x86_64/install.html (edit: the URL is now invalid because the issue was fixed locally)

--- doxygen.cmake~      2013-09-05 10:29:53.000000000 +0200
+++ doxygen.cmake       2013-12-14 17:52:58.000000000 +0100
@@ -41,15 +41,6 @@
     SET(HAVE_DOT NO)
   ENDIF(DOXYGEN_DOT_FOUND)

-  IF(UNIX)
-    SET(MAKE make)
-  ELSEIF(WIN32)
-    SET(MAKE nmake)
-  ELSE(UNIX)
-    MESSAGE(FATAL_ERROR
-      "Doxygen documentation generation not supported on this platform.")
-  ENDIF(UNIX)
-
   # Teach CMake how to generate the documentation.
   IF(MSVC)
     # FIXME: it is impossible to trigger documentation installation
@@ -66,7 +57,7 @@
       COMMENT "Generating Doxygen documentation"
       )

-    INSTALL(CODE "EXECUTE_PROCESS(COMMAND ${MAKE} doc)")
+    INSTALL(CODE "EXECUTE_PROCESS(COMMAND ${CMAKE_MAKE_PROGRAM} doc)")
   ENDIF(MSVC)

   ADD_CUSTOM_COMMAND(

Clang-Format style configuration

cc @gergondet @Galdeano @stanislas-brossette

Since the jrl-cmakemodules are widely used in our projects, it could be interesting to bundle a (default) clang-format style configuration that people could use. Most editors also support it: Vim, Emacs, SublimeText, Visual Studio etc.

But first, we would need to agree on a proper format/coding style. A list of options is available here, and usually the first step is to set BasedOnStyle to some famous style guide.

Obviously, jrl-cmakemodules users would not be forced to use this, and could still decide to use their own coding style (or none at all), but this could be valuable for new projects/developers.

Automate release with GitHub API

Cf https://github.com/blog/1645-releases-api-preview

We could use CURL to create the release on the site and upload the tarball generated by make dist.

cc @olivier-stasse

Consistent testing between projects

cc @thomas-moulard @olivier-stasse @francois-keith

In order to speed things up on Travis (since we're often reaching the deadly 50-min limit), I was considering changing build_git_dependency() in jrl-travis to disable test compilation for dependencies (unless explicitly asked). This is something that was observed with RobOptim, so it may also concern other projects.

• 1°) We could use a simple check with an optional variable, e.g.:

  OPTION(BUILD_TESTS "Build test programs" OFF)
  IF(BUILD_TESTS)
      ADD_SUBDIRECTORY(tests)
  ENDIF(BUILD_TESTS)

• 2°) We could also use EXCLUDE_FROM_ALL with ADD_EXECUTABLE when adding tests, then add a dependency to trigger compilation when running make test, or expect a make check to be run before that (cf. CMakeEmulateMakeCheck).

I guess that no matter what we choose here, we need to make sure that all JRL/LAAS projects using the jrl-umi3218 tools follow the same guidelines for their tests, so that Travis scripts can be modified accordingly. If this question was already asked and/or answered elsewhere, please let me know as well ;-)

Correctly link to libraries in pkg-config macros

In ubuntu 11.10, ld used as default the option --as-needed, which makes the order of the arguments in the command line important. See:
https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition

When using cmake macro
set_property($target linker_flags $ldflags)
the linker_flags are placed before the target in the compilation command line, which can lead to improper linkage.

One solution seems to be the use of TARGET_LINK_LIBRARIES($TARGET $LDFLAGS) instead, which places the libraries after the target in the command line.

See commit
127e62418f415214d2ea2000fb85bd9391013c03
on branch topic/sdalibar

Getting documentation cross-links to work

Hi,

Has anyone using the jrl-cmakemodules in combination with jrl-travis managed to get the cross-links between projects to work?

In my case, I've setup the proper TAGFILES entries in the RBDyn repository but in the online doc the links to the SpaceVecAlg library (e.g. click sva::RBInertiad on this page) are definitely not correct. Part of the problem seems to be that doxygen does not generate any installdox script in my case but I'm not sure why...

I think this issue is somewhat related to #3 but I'm having trouble to get this feature to work even with a single TAGFILE entry. One possibility I see is to not rely on installdox and simply sed the local links to a generally correct github url (e.g. for a project organization/repo replace $install_dir/share/doc/repo/doxygen-html by organization.github.io/repo/doxygen/HEAD) based on the entries in a new argument to the update-doxygen-doc.sh script.

linking dynamic graph modules with libpython

Hi

I am packaging dynamic-graph-python for debian, and found some issues when creating python modules with cmake. Specifically, during linking of libpython with the python modules.

The issue: Debian warns against linking against libpythonX.Y, as /usr/bin/pythonX.Y already contains the full python runtime (atleast for debian and ubuntu) From the Debian Python Policy:

Some distributions link extensions to libpython, but this is not the case in Debian as symbols might as well be resolved by /usr/bin/pythonX.Y which is not linked to libpython.

The warning:

dh_python2:427: public extension linked with libpython2.7: library_name.so

The solution: The solution would be to remove TARGET_LINK_LIBRARIES(${PYTHON_MODULE} ${LIBRARYNAME} ${PYTHON_LIBRARY}) from https://github.com/jrl-umi3218/jrl-cmakemodules/blob/master/python.cmake#L113

Uninstall and automatic cmake

When doing make uninstall, it seems cmake . is run. This prompts cmake to look for required package dependencies. If one of them has already been removed, the dependency will not be found and the uninstallation will fail.
Since the purpose of running make uninstall is to remove the package, it should not matter whether the package dependencies are there or not and the uninstallation should succeed regardless

Fix name clash in variable name "PKG_CONFIG_VERSION" in pkg-config.cmake

PKG_CONFIG_VERSION is used by FindPkgConfig.cmake to define the minimal
required pkg-config version. It is also used in pkg-config.cmake for the generation of
.pc files.

This breaks in jrl-mathtools on Gentoo because FindBLAS.cmake uses
FindPkgConfig.cmake after inclusion of pkg-config.cmake, overwrites
PKG_CONFIG_VERSION, and lead to a corrupt jrl-mathtool.pc file (with the wrong
version).

It is probably a bad idea to use PKG_CONFIG_ as a prefix for variables anyway.
Maybe rename all those PKG_CONFIG_* to e.g. JRL_* ?

why not release this project as a standalone project?

Issues that are fixed in this repository are really hard to propagate into all your projects using jrl-cmakemodules.

Wouldn't it be better to release jrl-cmake-modules as a standalone package ?

Python install path for Debian-based distributions

cc @jorisv, @thomas-moulard, @francois-keith

python.cmake currently relies on the following function to set the install directory:

import sys, os
print os.sep.join(['lib', 'python' + sys.version[:3], 'site-packages'])

One-liner:

python -c "import sys, os; print os.sep.join(['lib', 'python' + sys.version[:3], 'site-packages'])"

Thus, we get:

   * Ubuntu 10.04: python 2.6 ---> lib/python2.6/site-packages
   * Ubuntu 12.04: python 2.7 ---> lib/python2.7/site-packages
   * Arch Linux:   python 2.7 ---> lib/python2.7/site-packages
   * Arch Linux:   python 3.3 ---> lib/python3.3/site-packages

However, for Debian/Ubuntu users, site-packages is not in the default path (but dist-packages is) and users have to update their paths manually, even if they target /usr or /usr/local. I understand that this is done on purpose, to distinguish user-installed packages from system packages. Not that AFAIK, non-Debian-based distributions (e.g. Arch Linux) do not have this distinction.

Still, some may want to install files to dist-packages when available (bump @jorisv), all risks considered, so that users do not encounter path-related problems, which can be useful for (for example) new Ubuntu users who do not even know what's actually happening backstage. We could then use:

import sys, os
from distutils.sysconfig import get_python_lib
print os.sep.join(['lib', 'python' + sys.version[:3], os.path.basename(get_python_lib())])

One-liner:

python -c "import sys, os; from distutils.sysconfig import get_python_lib; print os.sep.join(['lib', 'python' + sys.version[:3], os.path.basename(get_python_lib())])"

With this, we get the "proper" paths:

    * Ubuntu 10.04: python 2.6 ---> lib/python2.6/dist-packages
    * Ubuntu 12.04: python 2.7 ---> lib/python2.7/dist-packages
    * Arch Linux:   python 2.7 ---> lib/python2.7/site-packages
    * Arch Linux:   python 3.3 ---> lib/python3.3/site-packages

I guess we could define a CMake variable (e.g. FORCE_DIST_PACKAGES) that leads to a call to one function if set, else to the other one in FINDPYTHON().

Any advice would be most welcome :-)

No error message when find visp fails

In the file cmake/image/visp.cmake, there is no test of the existence of the file visp-config.
As a result, if the executable does not exist, there is no error message, and the compilation fails at the compilation of the code as soon as the headers of visp are needed (namely in llvc), instead of during the compilation of the cmake project.

I suggest to add a preliminary test such as
EXEC_PROGRAM(${VISP_CONFIG} RETURN_VALUE visp-config-found)
and display an error message requiring to add the path to VISP_CONFIG to the PATH if not found.

IMOE, I tried to compile llvc, didn't find Visp, and supposed first that it was because VISP_ROOT or VISP_ROOT_DIR was not found (which was the case for open_cv). It took me some time so see that the findVisp process used was the one of jrl-cmakemodules, not the one in the package CMakeModules.

Fix Python site path detection

Currently, our modules are installed in dist-packages, it should be site-packages.

import sys, os; print os.sep.join([sys.prefix, 'lib', 'python' + sys.version[:3], 'site-packages'])

pkg-config : issue with SYSTEM in include_directories

When doing include_directories here
https://github.com/jrl-umi3218/jrl-cmakemodules/blob/master/pkg-config.cmake#L764
and here
https://github.com/jrl-umi3218/jrl-cmakemodules/blob/master/pkg-config.cmake#L766
the SYSTEM option is used.
It forces to uses -isystem instead of -I and change the order of inclusion with the header files.
It happens to be breaking the chaining of workspace in one of our ros package.
Do you mind if we remove them or is there any particular rational behing this choice ?

Suffix of the files included by doxygen

Hello

I noticed that the only headers considered during the compilation of the doxygen documentation are those with a .hh suffix
(this is defined in the file doxygen/Doxyfile.in).

Would it possible to add .h files too ?
I understand that parsing only .hh files is a way to force users to maintain code coherency inside the SoT, but I think it could be useful for others projects or if the projects use c headers for exceptional cases (such as cfsqp).

François

Automatic documentation for boost python.

Although not related to CMake, I post this issue here because the problem was encountered in many packages and the best place to provide a solution is this package.
This is mostly for reporting as I have no time to allocate to this at the moment.

Problem

A C++ library can be easily exposed in Python, using for instance boost python. If the C++ library is already documented using Doxygen, documenting the Python bindings in somewhat tedious as it duplicates the already written documentation.

Solution

1. make Doxygen generate XML documentation for your project. There is no need to install it if all the bindings are in the same package.
2. using a Python script similar to https://github.com/jmirabel/hpp-python/tree/master/doc, generate a C++ file containing the documentation for all the functions of your C++ code. There are two possible formats, one using templates, the other using a std::map. At the moment, I am not able to say which one is preferable.

Format using templates

template <typename FunctionPrototype> struct doxygen_doc
{
inline static const char* docstring() { static const char* ds = "undocumented function"; return ds; }
}
// A template specialization for each C++ function that Doxygen knows.

3. in the Python bindings code, use the file generated above to fill the documentation of your classes, methods, (attributes?)...

Trigger target generation at install in a portable way.

Currently, tests and documentation are generated either
by calling a custom target or automagically at install.

    INSTALL(
      CODE "EXECUTE_PROCESS(COMMAND ${MAKE} doc)"
      FILES ${CMAKE_CURRENT_BINARY_DIR}/doc/${PROJECT_NAME}.doxytag
      DESTINATION share/doc/${PROJECT_NAME}/doxygen-html)

(where CMAKE is make or nmake depending on the platform).

Unfortunately this approach does not work yet with MSVC (and maybe the other CMake supported IDE). For now doc is tagged as ALL so that documentation is generated each time make is called.

It would be nice to find a better way to handle this when using MSVC.

Potential issue with the macros PKG_CONFIG_APPEND_*

Hello everyone

There is a potential issue with the macros PKG_CONFIG_APPEND_*, since the command macro only consider one parameter. As a result, a list of parameters will be truncated and only the first one will be considered.

For example, doing:

  PKG_CONFIG_APPEND_LIBS_RAW(test1;test2)
  PKG_CONFIG_APPEND_LIBS_RAW(test3 test4)
  MESSAGE("  PKG_CONFIG_LIBS =  ${PKG_CONFIG_LIBS} ")

returns

 PKG_CONFIG_LIBS = test1;test3

To avoid this issue, a method consists in adding quotes around the parameters (so as to make a string rather than a list):

  PKG_CONFIG_APPEND_LIBS_RAW("test1;test2")

Luckily this error appears only twice and can be easily corrected : in boost.cmake and lapack.cmake

PS: This issue has been observed for both cmake 2.6.4 and 2.8, and under unix, XP and mac.