acts: new variant cxxstd

[wdconinc]

ACTS supports C++20, and so does ROOT as a (conditional) dependency. This has been (continues to be) hard to express concisely, and the past solution has unnecessarily restricted ROOT to C++17, which in turn imposes restrictions on other ROOT dependents that support C++20. The past solution was also unnecesarily restrictive in combining the C++ standards with version ranges when ROOT provided the TGeo features required by ACTS.

I think this loosened set of dependencies and added set of conflicts addresses the actual requirements.

I'll mark this as draft, and consider it a request for comments. Thinking through this 3-dimensional inverted-logic puzzle has been making my head hurt.

[HadrienG2]

How would you feel about adding a cxxstd flag to Acts and propagating it to ROOT ? This would allow reduced use of the conflicts mechanism, which I think would be preferable since in my (perhaps outdated) experience it has had a historical tendency to produce unclear error messages when an incompatible configuration is specified.

[wdconinc]

I feel that all these cxxstd variants in HEP packages are misrepresenting what a C++ standard really is supposed to be: it's not a configuration setting for the user to pick (usually) but a requirement on the compiler determined by the standard for which the codebase was written (of course, I don't need to explain that to anyone here). Maybe some developers (like ACTS) can and do guarantee that C++17 code can also be compiled correctly with the C++20 standard, but that's not always how the cxxstd variant is used. People seem to think that if they use a larger value of cxxstd then their code will run 'better' or 'faster'...

But, yeah, it might make the logic easier here. One thing I'm not clear about is whether requiring ROOT with the same C++ standard is strictly needed (regardless what ROOT says). It usually becomes necessary when there is significant logic inside the ROOT headers that are included in downstream packages. Are we using more than the interfaces to TGeo objects? Would acts cxxstd=20 even require root cxxstd=20 or is that already too strict?

In any case, I'll make the change to add cxxstd so we can propagate this and start using ACTS with C++20 :-)

[wdconinc]

Not quite sure I like the ergonomics of import _ConditionalVariantValues here, but it allows us to use a single list with conditional values for cxxstd.

Also:
@spackbot fix style

[spackbot-app]

Let me see if I can fix that for you!

[spackbot-app]

I was able to run spack style --fix for you!

spack style --fix

==> Running style checks on spack
  selected: isort, black, flake8, mypy
==> Modified files
  var/spack/repos/builtin/packages/acts/package.py
==> Running isort checks
  isort checks were clean
==> Running black checks
All done! ✨ 🍰 ✨
1 file left unchanged.
  black checks were clean
==> Running flake8 checks
var/spack/repos/builtin/packages/acts/package.py:7: [F401] 'spack.variant.Value' imported but unused
  flake8 found errors
==> Running mypy checks
Success: no issues found in 577 source files
  mypy checks were clean

Keep in mind that I cannot fix your flake8 or mypy errors, so if you have any you'll need to fix them and update the pull request. If I was able to push to your branch, if you make further changes you will need to pull from your updated branch before pushing again.

I wasn't able to make any further changes, but please see the message above for remaining issues you can fix locally!

[HadrienG2]

I feel that all these cxxstd variants in HEP packages are misrepresenting what a C++ standard really is supposed to be: it's not a configuration setting for the user to pick (usually) but a requirement on the compiler determined by the standard for which the codebase was written (of course, I don't need to explain that to anyone here). Maybe some developers (like ACTS) can and do guarantee that C++17 code can also be compiled correctly with the C++20 standard, but that's not always how the cxxstd variant is used. People seem to think that if they use a larger value of cxxstd then their code will run 'better' or 'faster'...

But, yeah, it might make the logic easier here. One thing I'm not clear about is whether requiring ROOT with the same C++ standard is strictly needed (regardless what ROOT says). It usually becomes necessary when there is significant logic inside the ROOT headers that are included in downstream packages. Are we using more than the interfaces to TGeo objects? Would acts cxxstd=20 even require root cxxstd=20 or is that already too strict?

In any case, I'll make the change to add cxxstd so we can propagate this and start using ACTS with C++20 :-)

Historically, builds of projects that link against ROOT have been failing when the ROOT C++ standard was not in sync with the project's standard. The cause is unfortunately all too well known : ROOT developers violate basic C++ sanity rules by adding polyfills for std::stuff from newer C++ standards when built against older C++ standards, and this in turn causes linker errors when linking "old C++" ROOT with "new C++" client code, as the same std::xyz symbol ends up referencing two completely different things (aka ODR violation UB).

This is true of at least C++14 vs C++17 build mode because in C++14 mode ROOT polyfills std::string_view, possibly other things I don't remember. Not sure if the ROOT team has started doing the same thing with C++20 functionality, but if so, if Acts wants to use C++20 functionality too, then it will need to link against C++20 ROOT to avoid ODR violation insanity...