build: Add explicit dependency for codegen

[stephenswat]

This commit establishes an explicit dependency between the targets we use in the code generation and the generated files. By default, CMake establishes no such dependency for INTERFACE targets, but CMake 3.19 allows us to add private sources to INTERFACE targets. This ensures that when ACTS is built, the codegen files are always ready to be installed. This is especially important for detray, which may opt not to even generate the files if no target depends on them, but they should still be available to detray clients.

[stephenswat]

Tagging @niermann999.

[github-actions]

📊: Physics performance monitoring for 79a6662

Full contents

physmon summary

• ✅ Particles fatras
• ✅ Particles geant4
• ✅ Particles ttbar
• ✅ Vertices ttbar
• ✅ Truth tracking (KF)
• ✅ Truth tracking (GSF)
• ✅ Truth tracking (GX2F)
• ✅ Truth tracking (KF refit)
• ✅ Truth tracking (GSF refit)
• ✅ CKF finding performance | trackfinding | single muon | truth smeared seeding
• ✅ CKF fitting performance | trackfinding | single muon | truth smeared seeding
• ✅ CKF track summary | trackfinding | single muon | truth smeared seeding
• ✅ Seeding trackfinding | single muon | truth estimated seeding
• ✅ CKF finding performance | trackfinding | single muon | truth estimated seeding
• ✅ CKF fitting performance | trackfinding | single muon | truth estimated seeding
• ✅ CKF track summary | trackfinding | single muon | truth estimated seeding
• ✅ Seeding trackfinding | single muon | default seeding
• ✅ CKF finding performance | trackfinding | single muon | default seeding
• ✅ CKF fitting performance | trackfinding | single muon | default seeding
• ✅ CKF track summary | trackfinding | single muon | default seeding
• ✅ Seeding trackfinding | single muon | orthogonal seeding
• ✅ CKF finding performance | trackfinding | single muon | orthogonal seeding
• ✅ CKF fitting performance | trackfinding | single muon | orthogonal seeding
• ✅ CKF track summary | trackfinding | single muon | orthogonal seeding
• ✅ Seeding trackfinding | 4 muon x 50 vertices | default seeding
• ✅ CKF finding performance | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ CKF fitting performance | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ CKF track summary | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ Ambisolver finding performance | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ IVF notime | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ AMVF gauss notime | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ AMVF grid time | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ Seeding trackfinding | ttbar with 200 pileup | default seeding
• ✅ CKF finding performance | trackfinding | ttbar with 200 pileup | default seeding
• ✅ CKF fitting performance | trackfinding | ttbar with 200 pileup | default seeding
• ✅ CKF track summary | trackfinding | ttbar with 200 pileup | default seeding
• ✅ Ambisolver finding performance | trackfinding | ttbar with 200 pileup | default seeding
• ✅ ML Ambisolver | trackfinding | ttbar with 200 pileup | default seeding
• ✅ AMVF gauss notime | trackfinding | ttbar with 200 pileup | default seeding
• ✅ AMVF grid time | trackfinding | ttbar with 200 pileup | default seeding
• 🔵️ Comparison - Truth tracking (GX2F vs KF)

❗️: Downstream build failure

• eic-shell EICrecon (cc @acts-project/epic-contacts)

[paulgessinger]

Does it not do that if it depends on the detray interface target? I'm changing detray to also contain compiled code in #5641, in that case at least it should trigger the generation, shouldn't it?

[stephenswat]

Does it not do that if it depends on the detray interface target? I'm changing detray to also contain compiled code in #5641, in that case at least it should trigger the generation, shouldn't it?

With the current detray CMake setup, the generation of this code is not triggered, even when we export a detray interface target. Let me see what the mechanism is with #5641.

[stephenswat]

Confirmed that #5641 also makes this problem go away.

[stephenswat]

@paulgessinger @niermann999 as far as I can tell there are actually 3 solutions to this problem:

1. To add the ALL keyword as I have done in this PR. Downside to this is that it might, in select pathological cases, cause the build system to generate more files than necessary, because it will cause all files to be generated by default, even the ones we don't install. Note that this doesn't mean we would e.g. generate detray codegen files when not building detray, because in that case the CMakeLists.txt file would never even be loaded.
2. To turn detray_core into a PUBLIC library rather than an INTERFACE one. That's simple and implemented in refactor(detray): Detray-level closed-set detector instantiation #5641. However it is worth noting that this only masks the problem, if at any point we add more codegen to INTERFACE targets or we turn detray back into an interface library for any reason, the problem will reappear.
3. Finally, as of CMake 3.19, it is possible to add private sources to INTERFACE targets (if that sounds confusing, I agree) which would explicitly establish a dependency between the target and the code generation in a way that works for both INTERFACE and PUBLIC targets. I think that's the most durable solution, and it avoids the possible over-generation of files that the ALL solution carries. This would carry the requirement to upgrade the minimum CMake version from 3.14 to 3.19.

Please let me know what y'all think.

[paulgessinger]

@stephenswat I like it. If we raise the CMake floor maybe we should do it in a separate PR though.

[stephenswat]

Waiting for #5647 so we can refactor this.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud