NPPS Leadership Team

[Brett Viren <bv AT bnl.gov>]

pinkenburg via Phys-npps-mgmt-l <phys-npps-mgmt-l AT lists.bnl.gov> writes:

> Anything new will take years to develop. ejana is an empty shell and
> still in the "does not even compile" stage, DD4hep also doesn't
> compile under SL7. I had some back and forth with the authors (who
> responded within minutes to the issue raised which is good) and it
> looks like gcc 4.8 is not supported (not completely C++11
> compliant). You need at least 4.9 but clang 7.0.0 which should be
> compliant also did not work, not sure what this means.

GCC 4 is ancient.  (As comparison, C++17 is the accepted standard in
neutrino software.  GCC 7 and 8 are used.)

Does this DD4hep example point to a more general and fundamental problem
in the EIC world?  One of reliance on ancient OS-provided compilers?  Is
there a need for EIC to provide developer and user runtime environments
for which EIC has control over versions?

If the answers are on the positive side of "maybe", there might be
fruitful collaboration between NP and HEP through the use of Spack both
to build binaries and to share them via CVMFS.

-Brett.

Attachment: signature.asc
Description: PGP signature