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.

XRootD headers aren't installed at all (all ROOT targets depend on it only privately), but vdt headers are needed when RVec.hxx is used from a ROOT that has vdt enabled. To cover the latter case, a small post-install test was added.

[github-actions]

Test Results

    20 files      20 suites   3d 2h 17m 54s ⏱️
 3 882 tests  3 882 ✅ 0 💤 0 ❌
68 622 runs  68 622 ✅ 0 💤 0 ❌

Results for commit 52dd787.

♻️ 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.