An enumeration dictionary for ECbmModuleId

The merge request adds an enumeration dictionary for ECbmModuleId. The purpose of this is to simplify the usage of the enumeration in yaml configs.

NOTE: The merge request depends on !2086 (merged), which in turn depends on !2085 (merged)

added core label

requested review from @f.uhlig

assigned to @v.friese

added 1 commit

• f5ce70f5 - An enumeration dictionary for ECbmModuleId

Compare with previous version

added 1 commit

• 52157792 - An enumeration dictionary for ECbmModuleId

Compare with previous version

added 4 commits

• f62d5c18 - moving algo/log to core
• 75cb579e - Moving cbm::algo::EnumDict to CbmUtility library as cbm::util::EnumDict;...
• ca7e3a54 - Merging CbmYamlInterface with CbmUtility; renaming yaml/Yaml.h -> CbmYaml.h
• 77d446cf - Moving cbm::algo::EnumDict to CbmUtility library as cbm::util::EnumDict;...

Compare with previous version

@f.uhlig, @p.-a.loizeau,

Could you please help me to figure it out, why building of the online container fails (https://git.cbm.gsi.de/computing/cbmroot/-/jobs/234930).

The difference of these merge to !2086 (merged) is following: https://git.cbm.gsi.de/s.zharko/cbmroot/-/compare/CbmUtility-lib...ECbmModuleID-dictionary. I introduced a dependency on CbmUtils to CbmData/OnlineData, which depends on xpu, yaml-cpp, GSL and fmt::fmt. The error message points at boost/log code, and all the errors seem to be actually deprecation warnings. For some reason these errors are not raised in !2086 (merged).

added 5 commits

• 77d446cf...84f6c07e - 4 commits from branch computing:master
• a5b5c237 - Moving cbm::algo::EnumDict to CbmUtility library as cbm::util::EnumDict;...

Compare with previous version

@s.zharko There are merge conflicts. Please rebase locally.

@f.uhlig Is the container problem solved?

@v.friese,

obviously the problem isn't solved. The stage building the container still crashes. It looks like a problem with the boost version. Actually I have no idea how the container is build in detail and how to debug this. This was all managed by Felix and I am not sure if anybody else has insight in this.

added 9 commits

• a5b5c237...08dc3388 - 8 commits from branch computing:master
• 612be65b - Moving cbm::algo::EnumDict to CbmUtility library as cbm::util::EnumDict;...

Compare with previous version

added 1 commit

• d7217cef - Bump online container version

Compare with previous version

I pushed what I think needs to be changed. Unfortunately the CI does not run now for other reasons.

added 5 commits

• d7217cef...21ab95f6 - 3 commits from branch computing:master
• 5e71b017 - Moving cbm::algo::EnumDict to CbmUtility library as cbm::util::EnumDict;...
• 2282ef2f - Bump online container version

Compare with previous version

Now it fails with an error related caused by the templated function not existing

In file included from /opt/cbm/src/core/data/sts/CbmStsDigi.h:16:
/opt/cbm/src/core/data/CbmDefs.h:120:70: error: no matching function for call to 'ToString'
inline std::string ToString(ECbmModuleId modId) { return std::string(cbm::util::ToString(modId)); }
                                                                     ^~~~~~~~~~~~~~~~~~~
/opt/cbm/src/core/utility/CbmEnumDict.h:64:20: note: candidate template ignored: requirement 'detail::EnumHasDict_v<ECbmModuleId>' was not satisfied [with T = ECbmModuleId]
  std::string_view ToString(T t)
                   ^

I think this is not related to the container environment but more likely to the different build flow of the online binary. One should be able to run the online binary build flow by running the commands in https://git.cbm.gsi.de/computing/cbmroot/-/blob/master/.ci/online/scripts/install.sh.

@s.zharko How do we proceed here? I have no clue why cbm::util::detail::EnumHasDict_v<EcbmModuleId> evaluates to false after calling the macro CBM_ENUM_DICT<ECbmModuleId> - but only when building the online container.

mentioned in merge request !2094

Ok, after the discussions we had, we can summarise: In your methods ToString, ToCbmModuleId and ToCbmModuleIdCaseInsensitive, you make use of cbm::util::FromString and cbm::util::ToString. These, however, are not present in the GPU case, which is why the compilation fails.

You would have to protect your methods like those in cbm::util by #if XPU_IS_CPU.

However, your methods are just wrappers of cbm::util::ToString and cbm::util::FromString; honestly, I do not see any added value here.

@s.zharko Since we now understand why this does not compile, and since this MR is in my understanding not longer needed, could you please close it or take other actions?