Idea #11707

Set values derived from product_deps in a ".cmake" file

Added by Ben Morgan about 4 years ago. Updated about 4 years ago.

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


Estimated time:


The CMake modules in Cetbuildtools determine configuration information such as install paths and qualifiers (covering compiler, build mode etc) using several files and programs. The rough sequence (using cetlib as an exemplar simple package) is:

  1. After setup_for_development is sourced, a file named cetpkg_variable_report is created in the build directory.
  2. That's created by the set_dev_products program, and information in it is derived from the ups/product_deps file in the source directory.
  3. The cetbuildtools module source:Modules/CetCMakeEnv.cmake derives:
    1. product/qualifier/etc info from Modules/CetGetProductInfo.cmake, that in turn runs source:bin/report_product_info, which reads the Key/Value info in the cetpkg_variable_report file and set CMake variables from these.
    2. install locations by running the various programs such as source:bin/report_bindir . These read the ups/product_deps file to print the requested info and set CMake variables.

As all of the information is ultimately derived by programs in cetbuildtools from the ups/product_deps file of the product, it may, depending on use cases be more robust to

  1. Upgrade set_dev_products to write a "cetpkg_variable_report.cmake" file in the build directory.
  2. Rather than flat Key/Value pairs, this could contain CMake "set(KEY "VALUE")" commands, combining the product/qualifier and install dirs info.
  3. Load that in CetCMakeEnv via CMake's include command.

Some post processing/validation of values might still be needed - for example, replacing things like "flavorqual_dir" "tags" in the install dirs. The same techniques could be used, just the source of the information changes from various places to one single Cet/UPS cmake "cache like" file.

Moving to using a ".cmake" file would allow:

  • Single point of contact for Cmake to grab UPS/Cet info, so cleaner and more robust.
  • Reduced dependence on environment vars and the user using these correctly (e.g. CETPKG_TYPE)
  • Provides a route towards decoupling UPS/CET policies from generic build policies.

To clarify the last point (NB, the following assumes UPS has been trained to set CMAKE_PREFIX_PATH correctly to find cetbuildtools), this would look something like

cmake_minimum_required(VERSION 3.3)
project(foo VERSION 1.17.2)

find_package(cetbuildtools 4.18.2 REQUIRED)

# ----- This section would be wrapped in a function like cet_cmake_env
option(USE_STANDARD_BUILD "no ups/cet specific features" OFF)


    "UPS build and install requested, but required cache file:\n" 
    "is not present in the build directory. Run setup_for_development first\n" 
# Use info loaded from file to 
# - validate qualifiers etc.
# - create defaults, e.g. for this example
# CMAKE_INSTALL_BINDIR = flavorqual_dir/bin

# - generic build configuration (flags etc)

# ----- End of the choice configuration section/function


# - Here's the decoupling - install locations use a standard variable,
# in a CET/UPS build it's value would be "<flavorqaul_dir>/bin" 
# in a "Standard" build it's value would be "bin" 

I have proof of principle code that patches the cetpkg_info_file function of source:bin/ to create the file, but this does mean it does a require cmake_parse_deps which may not be wanted. I'm also not sure of further use cases that might affect things like:

  • Is setup_for_development a once per build dir operation? In other words, how often might the CMake file need regenerating?
  • Should any of the variables set be user-modifiable or always CACHE FORCEd? I assume the former to ensure enforcement of policy.
  • I've seen that the presence of MRB env vars can modify certain things like overall qualifiers and paths - could MRB related info also be written into the file (so helping to decouple cetbuildtools from MRB)?

If those can be clarified, I can adjust the patches and inclusion check/validation as needed.


#1 Updated by Marc Paterno about 4 years ago

  • Status changed from New to Accepted

Our understanding is this idea contains details of the discussions ongoing between you, Lynn and Jim Amundson.

Since this kind of change relies on other underlying work being done first, we will wait for conclusions from the ongoing discussion of where our build system is going before we take actions.

Also available in: Atom PDF