feat: Decouple DD4hep detector construction from ACTS

[paulgessinger]

This is done via a new glue library ActsDD4hep that lives here.

[codecov]

Codecov Report

Merging #1241 (40151ea) into main (8948fa3) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #1241   +/-   ##
=======================================
  Coverage   47.89%   47.89%           
=======================================
  Files         375      375           
  Lines       19588    19588           
  Branches     9214     9214           
=======================================
  Hits         9382     9382           
  Misses       3822     3822           
  Partials     6384     6384           

📣 Codecov can now indicate which changes are the most critical in Pull Requests. Learn more

[paulgessinger]

Still have to sort out the downstream build scenario. Currently the ActsDD4hep glue lib cmake config does not get installed in this scenario.

[paulgessinger]

@asalzburger can you review this?

[asalzburger]

This is a straight forward move of the ActsExtension.
Approved.

[asalzburger]

I suppose this one is updated with the ODD PR - and can go in?

[paulgessinger]

Yes ODD should be all up to date.

[timadye]

Hi @paulgessinger,

Very nice to see this all sorted out. However, with this update, locally-run pytest started failing for my setup:

E               RuntimeError: Unable to find OpenDataDetector factory library. You might need to point LD_LIBRARY_PATH at it
Examples/Scripts/Python/common.py:46: RuntimeError

I think there are two issues here:

1. I was building with -DACTS_BUILD_EXAMPLES_DD4HEP=on, but not -DACTS_BUILD_ODD=on. Of course that won't support the ODD any more, but maybe the tests like test_odd in test_detectors.py should be disabled based on ACTS_BUILD_ODD, rather than ACTS_BUILD_EXAMPLES_DD4HEP. (Though actually those tests (like dd4hepEnabled) aren't directly on the build options.)
2. I didn't have build/thirdparty/OpenDataDetector/factory in my $LD_LIBRARY_PATH. It looks like getOpenDataDetector is supposed to set that automatically, but that doesn't seem to work. Can this be fixed, or do we need to add this as an extra instruction or setup.sh.

I worked round both these issues, and have the ODD tests run in pytest, so it's no big deal for me. I hope it's still useful for me to comment on this, and it's OK to comment here in the already-merged PR. Of course if you think it's worth it, I could submit an issue.

[paulgessinger]

Unfortunately, you'll have to manually adjust your LD_LIBRARY_PATH variable to where the ODD library and components file is located.

I was unable to handle this automatically at the python level. We could indeed try to be smart with our python setup.sh, or add an additional one. Note that you have the option of building ODD separately now, and ODD produces its own setup.sh that should set this up correctly. I don't think it's present in the integrated build though.

[timadye]

Yes, maybe the python setup.sh is the best place. I was thinking about this_acts.sh, but I guess people don't use that - and anyway for me it just adds /usr/local/lib64, not $BUILD_DIR/lib64.

I have my own setup.sh script, so added build/thirdparty/OpenDataDetector/factory there.

[timadye]

Remaining Python questions:

• If the getOpenDataDetector LD_LIBRARY_PATH setting doesn't work any more, maybe better to replace it with a check and error.
• Can we change the relevant dd4hepEnabled tests to oddEnabled tests?