Skip to content

Misc toolchains updates (a.k.a. C++17 on the CTP7)

Laurent Petre requested to merge feature/toolchains-misc-updates into main


This MR introduces miscellaneous improvements related to the various toolchains used by cmsgemos. In particular, this MR serves two main goals:

  1. Finally allow the usage of C++17 for the CTP7 target (and thus gemhardware). This was long considered and the support of additional targets makes it even more needed. Such an improvement came rather naturally from the usage of a modern cross-compiler (LLVM 14) for the soon-to-be-supported X2O.
  2. Reduce the number of external dependencies in order to better control the versions and simplify dependency handling in new targets (e.g. X2O).

In more detail:

  • Build the GEM function manager from the top-level directory
  • Update LLVM to version 14.0.6 (from version 7.0.1)
    • And use it to compile gemhardware in C++17 mode, including for the CTP7 target
  • Embed LMDB and log4cplus in the provided dependencies
  • Update all dependencies to the latest stable compatible version
    • {fmt}, libpqxx, LMDB, log4cplus, pybind11
  • Check whether or not Xerces-C++ is available at the configuration stage
  • Remove the dependency on Protobuf (see #242 (closed) for more details)

Smaller changes and bugfixes have also been introduced and can be found in the commit messages.

Additional considerations:

  • Requires new CTP7 libraries
  • Requires to update the LMDB address table (even in absence of firmware change)
  • Requires to restart the gemrpc service, ideally all GEM services on the backend board
  • The CI requires a new Docker image that is incompatible with the other branches. It will be triggered only once the MR is about to be merged.

Related Issue

Fixes #64 (closed) and #242 (closed).

How Has This Been Tested?

Taking runs on the GE1/1 integration setup is seamless. Using and gempy for OptoHybrid tests is working like a charm. Cases for which exceptions are forwarded from the backend board to the DAQ machine have been tested as well.

Nevertheless, considering the complexity of the changes, additional tests (e.g. calibration scans), by different people on different setups, are more than welcome.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)


  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.
Edited by Laurent Petre

Merge request reports