NPPS Leadership Team

[Torre Wenaus <wenaus AT gmail.com>]

I've put on the live notes page a question to our DD4hep expert speaking later, does it work on SL7.

On Wed, Jul 10, 2019 at 8:42 AM Brett Viren via Phys-npps-mgmt-l <phys-npps-mgmt-l AT lists.bnl.gov> wrote:

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.
_______________________________________________
Phys-npps-mgmt-l mailing list
Phys-npps-mgmt-l AT lists.bnl.gov
https://lists.bnl.gov/mailman/listinfo/phys-npps-mgmt-l