Feature #12317

Rationalize CMake module locations and dictionary generation across all gallery suite packages

Added by Christopher Green over 4 years ago. Updated about 4 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Spent time:
SSI Package:


This issue covers the work detailed in the following email sent to the artists list on 2016-04-08:


The following changes will be made to the art suite and friends today. Please read them to see how you will be affected, and let me know immediately if you believe they will cause problems for you or others.

  • Following investigations by David D. and Paul Russo, an issue has been identified in the way ROOT6 builds its records of where to find headers for Cling and JIT. The genreflex stage of the build system is being tweaked to accommodate it, but it puts constraints on the construction of #include lines: they must include relative paths from the package top level directory for any in-package headers. ROOT and genreflex headers are not affected by this because of their packages structure and configuration. Given how the ROOT rootmap header-finding system works however, there is a safety issue with respect to the uniqueness of paths to headers with the same name given the exact make up of -I options which leads us additionally to move the entire test/ tree from the top level into the package-named level: e.g. art's test/ directory moves down to art/test/. As a result, I would recommend that any downstream package building dictionaries for ROOT 6 ensure that their header include paths are unique among all possible packages that could end up in the same MRB development build.
  • I plan to reinstate ArtMake.cmake in art, removing it from canvas. Instances of art_make and friends in canvas (and possibly Gallery) will be changed to cet_make.
  • checkClassVersion and friends (including ArtDictionary.cmake) will remain in canvas and be removed from art.
  • The (currently-deactivated) tests of generated skeleton code will be reinstated in art.
  • Product configurations will be changed to set CMake module paths appropriately (in -cmake.config files), rather than requiring explicit inclusion in every package using CMake modules from an external product.

Again, please let me know ASAP if you have any problems or queries regarding the above.



#1 Updated by Christopher Green over 4 years ago

  • % Done changed from 0 to 100

Implemented in cetbuildtools v5_00_01, and in the current heads of master or develop as appropriate in cetlib through critic.

#2 Updated by Christopher Green over 4 years ago

  • Status changed from Assigned to Resolved

#3 Updated by Kyle Knoepfel about 4 years ago

  • Target version changed from 2.01.00 to 2.00.01

#4 Updated by Kyle Knoepfel about 4 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF