I used this repository as a testbench for Github Actions. This is a first WIP multiplatform version I developed.

From these first tests, Github Actions are amazing :) The platform is very generic and it allows sharing actions through repositories. Given its generality, we should discuss f2f how to proceed organization-wise :tada:

cc @traversaro @pattacini @vtikha @claudiofantacci

Some variable are missing before invoking install_basic_package_files() in the main CMakeLists.txt (line #70).

In particular, just before line #70, a

get_property(${PROJECT_NAME}_TARGETS GLOBAL PROPERTY ${PROJECT_NAME}_TARGETS)

is missing to properly use the associated global variable.

Furthermore, for install_basic_package_files() to work properly, the following 2 variables need to be declared:

BUILD_${PROJECT_NAME}_INCLUDEDIR
INSTALL_${PROJECT_NAME}_INCLUDEDIR

I have an implementation that seems to work fine, even though it is not a clean solution in the case a user uses EXTRA_PATH_VARS_SUFFIX.

We should briefly discuss a solution when we have some time :-)

In the template, we recommend to add a new option ENABLE_RPATH to control whether or not enable rpath on the installation binaries : https://github.com/robotology/how-to-export-cpp-library/blob/master/CMakeLists.txt#L57 .

I noticed that now YARP deprecated the option for doing that, and instead is using the CMake existing option CMAKE_SKIP_INSTALL_RPATH to control if enabling installation rpath https://github.com/robotology/yarp/blob/eeeb98345d528ef56187b06c3712fdd66fadeb08/doc/installation/install_linux.dox#L165 . Using an already existing CMake variable seems to be a good idea. I propose to do the same here, but listing CMAKE_SKIP_INSTALL_RPATH explicitly as an option like we do with BUILD_SHARED_LIBS and BUILD_TESTING.

Not really header only, but just lot of header files and no target. I tried add_library(${LIBRARY_TARGET_NAME} INTERFACE)

but I can't do

set_target_properties(${LIBRARY_TARGET_NAME} PROPERTIES VERSION       ${${PROJECT_NAME}_VERSION}
                                                        PUBLIC_HEADER "${${LIBRARY_TARGET_NAME}_HDR}")

I can't set the PUBLIC_HEADER property so none of the header files are being installed.

• Update YCM files to latest version (0.8.1)
• Use EXPORT instead of TARGETS_PROPERTY in install_basic_package_files
• Require CMake 3.5
• Build position independent code and disable compiler extensions
• Add optional dependency on YCM

With this PR we now have a refreshed, shiny and awesome CMake template for exporting Cpp libraries!

In particular I tried to address all the entries of #33 by

• Migrating Travis to Xenial and Xcode9.4, using addons for Homebrew (see #29).
• Create a matching alias library with namspace prefix, as reported in Chapter 16.2 of C. Scott's Professional CMake (see #30).
• Add header-only library template (see #31). This change had quite some implications. I found it useful to have a template just for that, as emerged from #28. This also impied the need for the project to export multiple libraries, not just one. Consequently, I had to add a variable with parent scopes to backprop to the main CMakeLists the name of the targets.
• Polish up ✨ the README 😎 (see #35).
• Change PATH (legacy keyword) in DIRECTORY in dox custom target (see #38).
• Last, but not least, I tried to provide guidelines and useful links about the complexity of mantaining a C++ library (see #34).

Let me know what you think and should you have any suggestion for improvements I'll try to address them asap! 👍

Closes #29, closes #30, closes #31, closes #32, closes #34, closes #35, closes #33, closes #38.

I recently renovated the Travis script for some robotology repos :

• https://github.com/robotology/robotology-superbuild/pull/108
• https://github.com/robotology/idyntree/pull/469
• https://github.com/robotology/gazebo-fmi/pull/24

To be honest, I mostly cargo-culted the Travis scripts from wb-toolbox and Dart, as discussed in https://github.com/robotology/robotology-superbuild/issues/96 .

I wonder if it could make sense to migrate the Travis template provide in here to run on modern Linux distribution, as the default Trusty distribution shipped by Travis is now 4-years old and not officially supported by the robotology software.

Hi everybody, I have to write a self-contained library for the new algorithm for calibration of FT sensors, so to avoid rewriting everytime the same structure I tried to set up a reference repo for a typical C++ library.

It is based on https://gitlab.robotology.eu/walkman/template-pkg that uses CMake/YCM, but with some additions (that would be out of scope for Walkman):

• example of use of generated_export_header() cmake macro for correctly exposing symbols and build shared library easily also on Windows,
• example of use of CTest and relative travis/appveyor scripts.

There are still a lot of things to polish/finish, but I guess it can still be a useful reference.

@francesco-romano @drdanz @arocchi feel free to suggest improvements, even for changes in the name of the repo/macros/source code structure. Perhaps Francesco can you add your usual rpath stuff?

cc @lornat75

I think here there's a typo:

https://github.com/robotology/how-to-export-cpp-library/blob/e23e399fce102ba8f87cd5269797513000b99794/CMakeLists.txt#L108-L111

It should be:

add_install_rpath_support(BIN_DIRS "${CMAKE_INSTALL_FULL_BINDIR}"
                          LIB_DIRS "${CMAKE_INSTALL_FULL_LIBDIR}"
                          INSTALL_NAME_DIR "${CMAKE_INSTALL_FULL_LIBDIR}"
                          USE_LINK_PATH)

cc @claudiofantacci @traversaro @drdanz

In https://github.com/robotology/how-to-export-cpp-library/blob/master/CMakeLists.txt#L26 we only list CXX in the LANGUAGES argument of the project call. This was done because this template is meant to show how to build a C++ library using CMake.

However, in the past we had problems with some Find<package>.cmake scripts that required the C language to be enabled, see for example https://bitbucket.org/ignitionrobotics/ign-cmake/pull-requests/44/fix-findfreeimagecmake-compatibility-with/diff .

Recently, we had the same problem with the FindHDF5.cmake with @pattacini and @vvasco . Given that the default setting (when LANGUAGES is not specified) is to enable both CXX and C, and classically Find<package>.cmake scripts have been written under those assumptions, I think it is a good idea to add C to the project LANGUAGES argument .

Related bug: https://github.com/robotology/yarp/issues/548 .

Otherwise, the default build type will be None, with no optimization enabled. The related code in YARP is the following (from https://github.com/robotology/yarp/blob/9a395f6e41e01d8d350b6a4e5e2b2f6c6f913b74/cmake/YarpOptions.cmake#L69):

if(NOT CMAKE_CONFIGURATION_TYPES)
  if(NOT CMAKE_BUILD_TYPE)
    # Encourage user to specify build type.
    message(STATUS "Setting build type to 'Release' as none was specified.")
    set_property(CACHE CMAKE_BUILD_TYPE PROPERTY VALUE "Release")
  endif()
endif()

We have been requiring the use of CMake 3.16 for robotology repos since September 2020 (see https://github.com/robotology/robotology-superbuild/issues/462). Now it could be a good time to review this repo and requiring CMake 3.16 also here, as these will drastically simplify some boilerplate.

This can be set by a user by mistake. The global property is the trustworthy location for this information.

Also set the standard build types as options on the build type so it is easy to switch in ccmake or cmake-gui.

In my experience, having finer control over exported symbols is much better than exporting all of them (either via the default behavior of GCC-and-friends or via WINDOWS_EXPORT_ALL_SYMBOLS). Among these benefits:

• smaller binary size (internal template instantiation names can be hidden)
• better inlining; if the compiler/LTO knows a symbol isn't exposed at all, it can be more aggressively inlined)
• less chance of someone using a symbol you didn't intend to expose (more a problem in C than C++)

Instead, GenerateExportHeader should be used to generate a header with _EXPORT macros to decorate classes, functions, and variables as being available to other libraries.

The current README, for what concerns the YCM dependency, recommends either vendoring the three files we require, or installing YCM externally.

Starting from CMake 3.11, as many of you already know well, a new FetchContent module was introduced. It allows downloading and configuring external projects during the configuration phase of the project (contrarily to ExternalProject). Therefore, it is an excellent solution for dependencies like YCM.

We should add in the README also this option. Sadly, the default CMake version on the current Ubuntu 18.04 LTS is still 3.10 though.

For a minimal example you can refer to the following implementation:

• Main CMakeLists.txt
• BootstrapYCM.cmake

cc @traversaro @claudiofantacci @pattacini @drdanz

The how-to-export-cpp-library can use the cookiecutter so that it can provide a simple command-line user experience to download and configure the CMake project template.