C++17, aliroot and o2

O²
1

You may know that we, muoners, have a small project alo that was supposed to hold code that might depend on both O2 and AliRoot.

So far we’ve been it using to :

    • compare (within the same process) O2 and AliRoot implementations of the MCH mapping
    • convert Run2 data (raw, sim, esd) to some Run3 muon proto/devel data format(s) (before proper inclusion into O2 or as one-off programs)
    • play with some custom dHLT components and aliceHLTwrapper to feed FairMQ chains

With the inclusion of c++17 into the O2 game, we get to rethink how we deal with alo dependencies, and I’d need some advice here.

The starting point is that AliRoot does not compile with c++17. At least not completely. At least not on our Macs (did not investigate further, but I guess it compiles on CentOS7 because gcc 7.3.1 might not fully c++17 compliant ?). And even if it would compile now, we will eventually reach a point where the compiler used for O2 won’t make it for AliRoot. Assuming here of course that there’s no plan to keep AliRoot compilable with latest c++ standards in the future.

So what we plan to do with alo is :

  1. remove the possibility to use the AliRoot and O2 libs within the same process. Exchange of information between the two will have to go through intermediate data, aka files.
  2. reading of Run2 data will be done by programs mainly based on AliRoot, but those programs will cherry pick (and compile with AliRoot options) some (muon) O2 source code to be able to output data in “Run3” form. That of course means those (muon) O2 parts must be compilable with an “old” c++ compiler
  3. stop playing with HLT altogether as anyway that was the initial plan …

One of the consequence of that plan is that we’d split alo in two : a part depending only on AliRoot libs (but cherry picking some O2 source) and a part depending only on O2 libs.

Would you have comments/criticisms to this plan ?

Thanks, a sorry for the long entry

2

IMHO the best route is to go via files or pipes. For what concerns the DPL we could add a special input which reads from stdin and chunks data into messages depending on some configuration options.