Extra CMake Modules for YARP and friends

Overview

YCM

Extra CMake Modules for YARP and friends

Documentation

Online documentation is available here: http://robotology.github.io/ycm.

GitHub Release Github Issues

Publications

  • A Build System for Software Development in Robotic Academic Collaborative Environments, D.E. Domenichelli, S. Traversaro, L. Muratore, A. Rocchi, F. Nori, L. Natale, Second IEEE International Conference on Robotic Computing (IRC), 2018 DOI: 10.1109/IRC.2018.00014 DOI

  • A Build System for Software Development in Robotic Academic Collaborative Environments, D.E. Domenichelli, S. Traversaro, L. Muratore, A. Rocchi, F. Nori, L. Natale, International Journal of Semantic Computing (IJSC), Vol. 13, No. 02, 2019 DOI: 10.1142/S1793351X19400087 DOI

  • Latest YCM release DOI

Build Status

OS X/Linux Windows
Build Status Build status
Issues
  • Latest YCM devel of robotology-superbuild on Travis with Docker blocks during bootstrap on

    Latest YCM devel of robotology-superbuild on Travis with Docker blocks during bootstrap on "Performing build step for 'YCM''

    See https://travis-ci.org/robotology/robotology-superbuild/builds/527715806 . Until yesterday, everything went fine. I already restarted a job, and the same problem appeared again.

    I wonder if the problem is related to this commit: https://github.com/robotology/ycm/commit/912e0d6f9ac5d54b3206f31c152eaa84e121893c

    opened by traversaro 27
  • Drop FindEigen3.cmake in favour of Eigen3Config.cmake

    Drop FindEigen3.cmake in favour of Eigen3Config.cmake

    The FindEigen3.cmake provided upstream in Eigen3 has several issues, that are addressed by this PR: https://bitbucket.org/eigen/eigen/pull-requests/281/improve-findeigen3cmake/diff .

    I recently discovered a new issue in FindEigen3.cmake (see https://github.com/robotology/idyntree/pull/354), but given the lack of interest upstream in fixing the problems in FindEigen3.cmake I think it would be difficult to get integrated upstream. Given that Eigen3 provides its own Eigen3Config.cmake file now so eventually the FindEigen3.cmake will be unused, I am wondering if we could ship our own FindEigen3.cmake module in YCM instead of downloading the upstream one.

    Resolution: Wontfix Component: Find Modules Component: 3rd Party 
    opened by traversaro 20
  • Add RPATH macro

    Add RPATH macro

    I'm (still) working on creating an RPATH macro.

    There are still some issues opened, but maybe @drdanz can help me fix them.

    1. Currently the first argument is only needed to create the option. I don't understand how I can use the CMakeDependentOption and the CMakePackageConfigHelpers to correctly parse the options.

    2. Currently this macro enables by default RPATH. Honestly I don't see any disadvantage of enabling RPATH w.r.t. the old way (i.e. libraries and bins with completely wrong search paths). Different is the case if one wants to enable e full-name installation. Disabling the macro does not lead to full-name installation, but simply revert to cmake default (and incomplete) RPATH configuration. At least, this is what I understood so far.

    3. This is an important point: The variable CMAKE_INSTALL_RPATH_USE_LINK_PATH simply automatically adds all the library search paths to the install rpath variable. This is handy but can lead to some problem. I try to explain better: Let's consider a gazebo-yarp plugin. It links to gazebo (default search path) and yarp (custom installation, but in my case it will reside at the same location of the plugin lib). If I set the CMAKE_INSTALL_RPATH_USE_LINK_PATH variable the resultant LC_RPATH will be

    $ otool -l libgazebo_yarp_controlboard.dylib | grep LC_RPATH -A2
              cmd LC_RPATH
          cmdsize 32
             path @loader_path/ (offset 12)
    --
              cmd LC_RPATH
          cmdsize 48
             path /usr/local/Cellar/gazebo4/4.0.0/lib (offset 12)
    --
              cmd LC_RPATH
          cmdsize 72
             path /usr/local/Cellar/gazebo4/4.0.0/lib/gazebo-4.0/plugins (offset 12)
    --
              cmd LC_RPATH
          cmdsize 56
             path /usr/local/Cellar/sdformat/2.0.1/lib (offset 12)
    --
              cmd LC_RPATH
          cmdsize 56
             path /usr/local/Cellar/protobuf/2.5.0/lib (offset 12)
    --
              cmd LC_RPATH
          cmdsize 56
             path /Users/makaveli/Projects/src/local/lib (offset 12)
    
    otool -L libgazebo_yarp_controlboard.dylib 
    libgazebo_yarp_controlboard.dylib:
        @rpath/libgazebo_yarp_controlboard.dylib (compatibility version 0.0.0, current version 0.0.0)
        @rpath/libgazebo_yarp_singleton.dylib (compatibility version 0.0.0, current version 0.0.0)
        @rpath/libYARP_OS.1.dylib (compatibility version 1.0.0, current version 2.3.63)
        @rpath/libYARP_sig.1.dylib (compatibility version 1.0.0, current version 2.3.63)
        @rpath/libYARP_math.1.dylib (compatibility version 1.0.0, current version 2.3.63)
        @rpath/libYARP_dev.1.dylib (compatibility version 1.0.0, current version 2.3.63)
        @rpath/libYARP_name.1.dylib (compatibility version 1.0.0, current version 2.3.63)
        @rpath/libYARP_init.1.dylib (compatibility version 1.0.0, current version 2.3.63)
        /usr/local/lib/libgazebo_transport.4.dylib (compatibility version 4.0.0, current version 4.0.0)
        /usr/local/lib/libgazebo_physics.4.dylib (compatibility version 4.0.0, current version 4.0.0)
           .....
    

    The only useful line is the first one (@loader_path/). All the others are useless because they refer to either full-name libraries (gazebo) or to yarp which is already "resolved" through @loader_path.

    If instead I disable the variable the result is the following:

    $ otool -l libgazebo_yarp_controlboard.dylib | grep LC_RPATH -A2
              cmd LC_RPATH
          cmdsize 32
             path @loader_path/ (offset 12)
    

    Of course this is more clean, but it requires the cmake developer to know all the paths of the installed dependent (shared) variables.

    1. the bin or lib variable is not strictly correct: maybe I should change it to target_dirs and lib_dirs.
    opened by francesco-romano 17
  • Make AddUninstallTarget FetchContent / add_subdirectory friendly

    Make AddUninstallTarget FetchContent / add_subdirectory friendly

    Similar to what we discussed in https://github.com/robotology/ycm/issues/162#issue-349119219, also AddUninstallTarget (or any other module that adds custom "global" targets) is not really compatible with the FetchContent / add_subdirectory pattern (see https://github.com/robotology/idyntree/issues/370#issuecomment-420705347).

    I think this can be elegantly addressed by adding the uninstallation code in a custom target ${PROJECT_NAME}-uninstall, and adding this target as a dependency to the uninstall target, eventually creating the uninstall target if it does not already exist.

    Something like (warning: this was not actually tested):

    add_custom_target(${PROJECT_NAME}-${_uninstall} COMMAND "${CMAKE_COMMAND}" -P "${_filename}")
    set_property(TARGET ${PROJECT_NAME}-${_uninstall} PROPERTY FOLDER "CMakePredefinedTargets")
    
    if(NOT TARGET ${_uninstall})
      add_custom_target(${_uninstall})
    endif()
    add_dependencies(${_uninstall}  ${PROJECT_NAME}-${_uninstall})
    

    cc @drdanz @claudiofantacci @ahoarau

    Type: Enhancement Module: AddUninstallTarget Component: Modules 
    opened by traversaro 16
  • Find a way to pass the same CMAKE_TOOLCHAIN_FILE to every cmake-based subproject

    Find a way to pass the same CMAKE_TOOLCHAIN_FILE to every cmake-based subproject

    For cross-compilation of a complete workspace, it could be convenient to be able to pass in some way the same CMAKE_TOOLCHAIN_FILE to every cmake-based subproject of a YCM-based superbuild.

    An alternative solution that could be implemented in CMake would be supporting specifying CMAKE_TOOLCHAIN_FILE as an environment variable. I remember that this solution was suggested somewhere in vcpkg docs, but I cannot find any reference for this. However, I think this was never proposed/discussed in the CMake mailing list/issue tracker, and it may be undesirable as it may increase even more complexity at the CMake level.

    Related conan issue: https://github.com/conan-io/conan/issues/1447 .

    Component: Modules Module: YCMEPHelper Resolution: Fixed 
    opened by traversaro 15
  • UseSWIG module requires CMake 3.14+

    UseSWIG module requires CMake 3.14+

    Commit https://github.com/robotology/ycm/commit/d8fc9ff7611aa6a8f4e159ca746268812e097a25 started fetching UseSWIG.cmake module from CMake 3.14.4 (was 3.8.2). This module requires CMake 3.14+, see these lines (CMP0078 and CMP0086 were introduced in CMake 3.13 and 3.14, respectively). Affects YCM 0.10.3.

    Related: https://github.com/robotology/ycm/issues/248. Cannot apply same solution (provide own YCM version of this module) easily because of those two CMake policy declarations, modern generator expressions (https://github.com/Kitware/CMake/commit/88dd5dc9ff405ee5bd63b15ea1e5219e5d029e12) and a major rework that requires CMake 3.11 (https://github.com/Kitware/CMake/commit/0bef9eb410566aa10536331d086d4a3ee265a526).

    Type: Bug Component: CMake Next Resolution: Fixed 
    opened by PeterBowman 14
  • RPATH support in Ubuntu

    RPATH support in Ubuntu

    This is really interesting, if today on Ubuntu 18.04 I execute the same command of https://github.com/robotology/ycm/issues/147#issuecomment-397527388, I get:

    [email protected]:~> objdump -x /iit/local/lib/libYARP_math.so | grep -2 PATH
      NEEDED               libc.so.6
      SONAME               libYARP_math.so.3
      RUNPATH              $ORIGIN/:$ORIGIN/../lib:$ORIGIN/../
      INIT                 0x0000000000008298
      FINI                 0x00000000000ba4e4
    

    Note that RPATH is no longer there. I warmly recommend reading this comment that applies to recent Ubuntu distros. Can you please check the behaviour on your system?

    Related to https://github.com/robotology/ycm/issues/147.

    cc @traversaro @drdanz @claudiofantacci @francesco-romano

    opened by diegoferigo 14
  • ExternalProject sync

    ExternalProject sync

    Update ExternalProject from CMake master and apply the patch to avoid deleting the clones.

    TODO:

    • [x] Proper testing on actual superbuilds
    • [ ] Test shallow clones
    • [ ] (optional, but recommended) Propose the change upstream.

    CC: @traversaro

    Type: Enhancement Component: CMake Next Module: ExternalProject Resolution: Merged 
    opened by drdanz 14
  • "No locks available." error while boostrapping a YCM superbuild

    While configuring the codyco-superbuild on the shared disk (NFS) of the new iCubGenova05 setup running Ubuntu 16.04 , I get this error:

     CMake Error at cmake/IncludeUrl.cmake:241 (file):
       error locking file
    
    
     "/usr/local/src/robot/codyco-superbuild/build/CMakeFiles/YCMEPHelper.cmake.cma
     ke"
    
       No locks available.
     Call Stack (most recent call first):
       cmake/YCMBootstrap.cmake:105 (include_url)
       CMakeLists.txt:84 (include)
    

    Placing the build in the "normal" filesystem running ext4 solves the problem. I guess the error is not directly related to ycm (probably the default configuration for the NFS server in Ubuntu 16.04 are different the lock server is not running by default) but it is worth opening an issue so future users with the same problem will now how to solve the problem.

    Type: Bug Module: IncludeUrl Component: Modules Resolution: Fixed 
    opened by traversaro 14
  • Test multiple CMake versions in Travis CI using docker

    Test multiple CMake versions in Travis CI using docker

    Implemented features:

    • Testing of CMake >= 3.1 on Linux environment
    • Tests on rc versions are allowed to fail
    • CMake archives caching
    • Linux generators:
      • Unix Makefiles
      • Ninja
    • Osx generators:
      • Unix Makefiles
      • Xcode

    TODO and comments:

    • CMake 3.0 has only i386 tarballs and it would require the installation of lib32 packages. Since this version will be deprecated sometime soon, I didn't add this exception
    • In osx, only CMake 3.6.2 (the one shipped inside Travis' virtualization environment) is tested. The support of multiple versions is already present in the build matrix, but I miss macOS knowledge to properly handle packages.
    Type: Enhancement Type: Reminder Component: Continuous Integration 
    opened by diegoferigo 13
  • Add the possibility to override the  module path in the autogenerated config

    Add the possibility to override the module path in the autogenerated config

    This is to have the possibility to find dependencies that may not be available given the default module path.

    It overrides the module path with the one provided through the option. In this way, the user may install custom find*.cmake and have them found also in dependent projects.

    cc @traversaro

    opened by S-Dafarra 12
  • Fix deploy workflow to PyPI

    Fix deploy workflow to PyPI

    Should fix https://github.com/robotology/ycm/issues/415. I do not explain to myself either why in all previous releases worked or why this time didn't.

    cc @traversaro.

    opened by diegoferigo 1
  • In deb packages's control file Section: devel should be Section: libs

    In deb packages's control file Section: devel should be Section: libs

    In the .deb packages generated in https://github.com/robotology/ycm/pull/410 , in the control file the Section: is devel, while in old packages it was Section: libs. It may be possible that this changes creates problem when the packages are uploaded in http://www.icub.eu/ubuntu/ , so from next release it would be great if we could switch back to Section: libs.

    fyi @Nicogene @mbrunettini @pattacini @davidelasagna

    opened by traversaro 0
  • Unable to determine default `CMAKE_INSTALL_LIBDIR` on Ubuntu 2022.04

    Unable to determine default `CMAKE_INSTALL_LIBDIR` on Ubuntu 2022.04

    Just got the following warning:

    -- YCM Version: 0.14.0 (0.14.0)
    CMake Warning (dev) at /usr/share/cmake-3.22/Modules/GNUInstallDirs.cmake:239 (message):
      Unable to determine default CMAKE_INSTALL_LIBDIR directory because no
      target architecture is known.  Please enable at least one language before
      including GNUInstallDirs.
    Call Stack (most recent call first):
      CMakeLists.txt:29 (include)
    This warning is for project developers.  Use -Wno-dev to suppress it.
    
    opened by pattacini 3
  • Fix automatic generation of website

    Fix automatic generation of website

    The website was last generated in August 2021 (see http://robotology.github.io/ycm/gh-pages/git-master/index.html) I guess manually. We should fix the generation of the website, ideally automatically.

    opened by traversaro 1
Releases(v0.14.2)
Owner
Robotology
Group software repositories of the iCub eco-system (but code developed is not necessarily iCub specific!).
Robotology
CMake checks cache helper modules – for fast CI CMake builds!

cmake-checks-cache Cross platform CMake projects do platform introspection by the means of "Check" macros. Have a look at CMake's How To Write Platfor

Cristian Adam 58 May 22, 2022
CMake modules to help use sanitizers

sanitizers-cmake CMake module to enable sanitizers for binary targets. Include into your project To use FindSanitizers.cmake, simply add this reposito

Matt Arsenault 274 Jun 14, 2022
CMake Community Modules

CMake Community Modules The CMake Community Modules are CMake modules created and maintained by the community. This repository's main product is the C

Edgar 1 May 12, 2022
CMake modules for some scientific libraries

A collection of CMake modules, which can mostly be used independently. The utilities for writing robust Find* modules might be useful until CMake take

Jed Brown 81 May 30, 2022
Common CMake modules

CMake Modules This repository contains common CMake modules and a collection of find scripts to locate non-CMake dependencies. The recommended way to

Eyescale Software GmbH 143 Jun 4, 2022
Additional CMake functionality. Most of the modules are from Ryan Pavlik

Additional CMake functionality. Most of the modules are from Ryan Pavlik

Lars Bilke 413 Jun 23, 2022
Ryan's CMake Modules Collection

This is a collection of CMake modules that I've produced during the course of a variety of software development.

Ryan A. Pavlik 845 Jun 22, 2022
A set of cmake modules to assist in building code

CMake 3 Tools Warning: These tools are being replaced by the Modern CMake. Some of the tools are still being maintained for now, but new projects shou

null 181 Jun 4, 2022
CMake scripts for painless usage of SuiteSparse+METIS from Visual Studio and the rest of Windows/Linux/OSX IDEs supported by CMake

CMake scripts for painless usage of Tim Davis' SuiteSparse (CHOLMOD,UMFPACK,AMD,LDL,SPQR,...) and METIS from Visual Studio and the rest of Windows/Lin

Jose Luis Blanco-Claraco 379 Jun 23, 2022
CMake module to enable code coverage easily and generate coverage reports with CMake targets.

CMake-codecov CMake module to enable code coverage easily and generate coverage reports with CMake targets. Include into your project To use Findcodec

HPC 76 Jun 1, 2022
unmaintained - CMake module to activate certain C++ standard, feature checks and appropriate automated workarounds - basically an improved version of cmake-compile-features

Compatibility This library provides an advanced target_compile_features() and write_compiler_detection_header(). The problem with those is that they a

Jonathan Müller 72 Apr 14, 2022
📦 CMake's missing package manager. A small CMake script for setup-free, cross-platform, reproducible dependency management.

Setup-free CMake dependency management CPM.cmake is a CMake script that adds dependency management capabilities to CMake. It's built as a thin wrapper

CPM.cmake 1.2k Jun 27, 2022
cmake-font-lock - Advanced, type aware, highlight support for CMake

cmake-font-lock - Advanced, type aware, highlight support for CMake

Anders Lindgren 37 Dec 30, 2021
cmake-avr - a cmake toolchain for AVR projects

cmake-avr - a cmake toolchain for AVR projects Testing the example provided The toolchain was created and tested within the following environment: Lin

Matthias Kleemann 156 Jun 20, 2022
Make CMake less painful when trying to write Modern Flexible CMake

Izzy's eXtension Modules IXM is a CMake library for writing Modern flexible CMake. This means: Reducing the amount of CMake written Selecting reasonab

IXM 99 Feb 14, 2022
[CMake] [BSD-2] CMake module to find ICU

FindICU.cmake A CMake module to find International Components for Unicode (ICU) Library Note that CMake, since its version 3.7.0, includes a FindICU m

julp 29 Apr 26, 2022
A fast build system that encourages the creation of small, reusable modules over a variety of platforms and languages.

Buck Buck is a build tool. To see what Buck can do for you, check out the documentation at http://buck.build/. Installation Since Buck is used to buil

Facebook 8.3k Jun 24, 2022
A program that automatically generates CMake and Meson configuration files for your Vala project

Autovala is a program and a library designed to help in the creation of projects with Vala and CMake. It also has support for Genie.

Sergio Costas 107 Apr 7, 2021
A template C++ repository, using CMake and Catch

C++ Project Template This is a template project for C++. It uses CMake to build and Catch for unit tests. It is integrated with Travis CI, and builds

Joshua Peterson 43 May 30, 2022