Make VDT a private dependency; don't install headers of builtins into the global install prefix

[hageboeck]

This improves the situation of #8655, by not unconditionally installing the XRootD and VDT headers into /include.

The only builtins that were publicly visible were XRootD and VDT. The former is already a private dependency, so its headers didn't need to be installed, any more. #22970
By outlining VDT from RVec.hxx, it can be made private, too. Therefore, it doesn't need to be installed, and modules are independent of whether or not VDT was present at build time, which fixes the last missing piece to close #9736.

A small post-install test was added to test that the RVec VDT functions work without an installed VDT.

[github-actions]

Test Results

    23 files      23 suites   3d 15h 49m 41s ⏱️
 3 856 tests  3 856 ✅ 0 💤 0 ❌
79 447 runs  79 447 ✅ 0 💤 0 ❌

Results for commit 75a613f.

♻️ This comment has been updated with latest results.

[guitargeek]

#ifdef R__HAS_VDT
#include <vdt/vdtMath.h>
#endif

#include <ROOT/RVec.hxx>

I was just suggesting to only forward declare vdt in this header 🙂 So ROOT builds with vdt=ON can also be used on systems where vdt is not in the default include path, which is improving the portability situation quite a bit:

• [RVec] Forward declare VDT functions in RVec.hxx header #22927

So we'd have to update your new post-install test when my PR gets merged.

Maybe a more robust way (independent of my PR getting merged or not) to test what you actually want to cover ("ensure that the VDT headers are found correctly"), is just to check that the #include <vdt/vdtMath.h> header can be found? This can even be done at the post install CMake level with the usual header availability checks, I don't think we need a dedicated compiled test for that.

Or is there an advantage of testing this indirectly via RVec.hxx that I'm missing?

[vepadulano]

LGTM, two minor comments.

[hageboeck]

#ifdef R__HAS_VDT
#include <vdt/vdtMath.h>
#endif

#include <ROOT/RVec.hxx>

I was just suggesting to only forward declare vdt in this header 🙂 So ROOT builds with vdt=ON can also be used on systems where vdt is not in the default include path, which is improving the portability situation quite a bit:

If VDT is not included, trying to call these functions would produce an error. So we are shifting the error on inclusion to an error on call. I think that's fair, but your installation is broken in both cases.
If you want, we can go ahead with the other PR, but I would still like to test that using a VDT function in RVec actually works if ROOT claims that it has VDT.

Maybe a more robust way (independent of my PR getting merged or not) to test what you actually want to cover ("ensure that the VDT headers are found correctly"), is just to check that the #include <vdt/vdtMath.h> header can be found? This can even be done at the post install CMake level with the usual header availability checks, I don't think we need a dedicated compiled test for that.

It's not exactly the same: If CMake finds the header (because you gave it enough search hints), you might still not be able to compile an RVec program, because we need to test that all the -I of the CMake target ROOT::ROOTVecOps are correct. That will be the case if we export things correctly, so I would like to keep compiling a program that includes RVec.hxx and tries to call a VDT function. What this program does is secondary, though, so any call of a vdt function will do.

So should we say:

1. Finish and merge [RVec] Forward declare VDT functions in RVec.hxx header #22927
2. Update the test in this PR here.

[guitargeek]

So should we say:

1. Finish and merge [[RVec] Forward declare VDT functions in `RVec.hxx` header #22927](https://github.com/root-project/root/pull/22927)

2. Update the test in this PR here.

Agreed with that! Let's continue the discussion in #22927 for now, and then adapt the test in this PR.

[hageboeck]

@guitargeek, here is what we discussed. VDT is now completely outlined, so we don't need to search it nor install it.

[guitargeek]

Thank you very much for this!

Now, the compiler can't decide to inline the RVec fast_* functions anymore, but given this is an unclear presumed performance benefit to a niche user group this is an acceptable tradeoff to get more relocatable builds without public dependencies!