Extra CMake Modules for YARP and friends

Related tags

Build Systems cmake robotics cmake-resources cmake-modules superbuild build-tool build-system yarp
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
Comments
  • 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:

    dferigo@iiticublap110:~> 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
  • Catch v3

    Catch v3

    Migration from Catch v2.13.4 to v3.2.1. This change probably triggers the release of YCM 0.15? @traversaro

    The idea is to have: Yarp 3.7.2 <-> ycm 0.14.2 YARP 3.8 (to be released, currently master) <-> ycm 0.15

    opened by randaz81 1
  • Add FinduSockets.cmake and FinduWebSockets.cmake find-modules

    Add FinduSockets.cmake and FinduWebSockets.cmake find-modules

    Add CMake modules to find the uSockets and uWebSockets libraries.

    They are supposed to be used as:

    find_package(uSockets REQUIRED)

target_link_libraries(<..> PRIVATE uSockets::uSockets)

    and

    find_package(uWebSockets REQUIRED)

target_link_libraries(<..> PRIVATE uWebSockets::uWebSockets)
    opened by traversaro 0
  • Support installing imported targets

    Support installing imported targets

    Hi, I am the developer of project options that uses install_basic_package_files from ycm internally for its package_project functionality.

    I have noticed that ycm fails to install IMPORTED targets. I have written a patch that detects such imported targets and installs them as a FILE instead of a TARGET.

    However, this still fails when calling the export function. This is because when the install(TARGETS ... EXPORT ...) is not called, no export exists.

    I am wondering if we can handle this corner case.

    See this for more information

    CMake Error at build/_deps/_ycm-src/modules/InstallBasicPackageFiles.cmake:660 (export):
  export Export set "test" not found.
Call Stack (most recent call first):
  build/_deps/_project_options-src/src/PackageProject.cmake:217 (install_basic_package_files)
  CMakeLists.txt:36 (package_project)
    opened by aminya 2
  • Error while downloading third party files

    Error while downloading third party files

    Today I had the following error while compiling YCM on Windows with Visual Studio 2022

    14>-- Cannot download file https://invent.kde.org/frameworks/extra-cmake-modules/-/raw/v5.79.0/COPYING-CMAKE-SCRIPTS
14>  Network problem or not existing file.
14>  CMake Error at D:/TeleoperationCode/robotology-superbuild/build/src/YCM/3rdparty/CMakeFiles/3rdparty-ecm.dir/ycm_download_COPYING_CMAKE_SCRIPTS_real.cmake:9 (file):
14>  file DOWNLOAD HASH mismatch
14>
14>    for file: [D:/TeleoperationCode/robotology-superbuild/build/src/YCM/3rdparty/CMakeFiles/3rdparty-ecm.dir/downloads/COPYING-CMAKE-SCRIPTS]
10>-- Using file cmake/modules/MacroFindGStreamerLibrary.cmake previously downloaded from qt-gstreamer git repository (ref a0e95b202a72b6d9e48bd1949ab6811c0f3c91c3)
7>Files from build-modules installed in CMake build directory
13>-- Using file cmake/FindEigen3.cmake previously downloaded from Eigen GitLab repository (ref a12b8a8c75ebef312509da643424951725519348)
8>C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(245,5): warning MSB8065: Custom build for item "D:\TeleoperationCode\robotology-superbuild\build\src\YCM\CMakeFiles\4de7a3b2c9b080a9797b837d14a6cbd4\README.VTK.rule" succeeded, but specified output "d:\teleoperationcode\robotology-superbuild\build\src\ycm\3rdparty\share\ycm\3rdparty\readme.vtk" has not been created. This may cause incremental build to work incorrectly.
8>C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(245,5): warning MSB8065: Custom build for item "D:\TeleoperationCode\robotology-superbuild\build\src\YCM\CMakeFiles\4de7a3b2c9b080a9797b837d14a6cbd4\FindFFMPEG.cmake.rule" succeeded, but specified output "d:\teleoperationcode\robotology-superbuild\build\src\ycm\3rdparty\share\ycm\3rdparty\findffmpeg.cmake" has not been created. This may cause incremental build to work incorrectly.
8>C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(245,5): warning MSB8065: Custom build for item "D:\TeleoperationCode\robotology-superbuild\build\src\YCM\CMakeFiles\4de7a3b2c9b080a9797b837d14a6cbd4\COPYING.VTK.rule" succeeded, but specified output "d:\teleoperationcode\robotology-superbuild\build\src\ycm\3rdparty\share\ycm\3rdparty\copying.vtk" has not been created. This may cause incremental build to work incorrectly.
8>Done building project "3rdparty-vtk.vcxproj".
14>      expected hash: [ff3ed70db4739b3c6747c7f624fe2bad70802987]
14>        actual hash: [da39a3ee5e6b4b0d3255bfef95601890afd80709]
14>             status: [22;"HTTP response code said error"].
14>  Retrying.

    In particular, it seems that it is not possible to see the raw file when using a branch (try to click on "Open raw" on https://invent.kde.org/frameworks/extra-cmake-modules/-/blob/v5.79.0/COPYING-CMAKE-SCRIPTS), while it is possible to see the raw file when using a permalink (try with https://invent.kde.org/frameworks/extra-cmake-modules/-/blob/ce726d388a59b941e2e6f6f487132532511af03d/COPYING-CMAKE-SCRIPTS)

    cc @traversaro

    opened by S-Dafarra 5
  • 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
Releases(v0.14.2)
Owner
Robotology
Group software repositories of the iCub eco-system (but code developed is not necessarily iCub specific!).
Robotology
GitHub http://robotology.github.io/ycm
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 65 Dec 6, 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 295 Dec 23, 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 2 Dec 14, 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 83 Dec 4, 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 144 Dec 27, 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 452 Dec 28, 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 891 Jan 9, 2023
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 201 Dec 21, 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 395 Dec 24, 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 82 Nov 30, 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 74 Dec 26, 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.6k Jan 9, 2023
cmake-font-lock - Advanced, type aware, highlight support for CMake

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

Anders Lindgren 39 Oct 2, 2022
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 163 Dec 5, 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 107 Sep 1, 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 Nov 2, 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.5k Jan 7, 2023
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 108 Oct 15, 2022
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 49 Oct 23, 2022