Incorrect Dependency on VDT

[krasznaa]

• Checked for duplicates

Describe the bug

The ROOTVecOps library incorrectly declares a PRIVATE dependency on the VDT headers.

https://github.com/root-project/root/blob/master/math/vecops/CMakeLists.txt#L27

(To be correct, it declares its dependency on VDT in a very silly way that does not make any sense to me...)

Even though it clearly "publicly" depends on those headers.

https://github.com/root-project/root/blob/master/math/vecops/inc/ROOT/RVec.hxx#L54

Expected behavior

When using the exported target ROOT::ROOTVecOps, I would expect to be able to use RVec.hxx just by linking my own target against ROOT::ROOTVecOps. Not having to care about the "internal" dependency of the ROOT code on VDT myself.

To fix, the following should happen:

• VDT should be used in the ROOT CMake configuration through an imported target, not through ${VDT_INCLUDE_DIRS} and ${VDT_LIBRARIES}. (Since these make relocation very hard.)
• Once ROOTVecOps depends on a library like VDT::vdt, ROOTConfig.cmake.in will need to include

find_dependency(VDT)

somewhere around here: https://github.com/root-project/root/blob/master/cmake/scripts/ROOTConfig.cmake.in#L88-L99

In such a setup, as long as builtin_vdt is "correctly" installed alongside ROOT, the configuration should start becoming correct under all circumstances.

To Reproduce

Don't really have a reproducer. But a CMake project like:

cmake_minimum_required( VERSION 3.10 )
project( VecOpsTest )

find_package( ROOT REQUIRED )

add_executable( VecOpsTest VecOpsText.cpp )
target_link_libraries( VecOpsTest PRIVATE ROOT::ROOTVecOps )

, with a simple

#include <ROOT/RVec.hxx>

int main() { return 0; }

(as VecOpsTest.cpp) should be able to produce an error. As long as ROOT and VDT headers are not in the same location. Which is usually the case unfortunately...

Setup

This is primarily an issue with "LCG builds" of ROOT. Where currently we have to manually take care of linking our code explicitly against VDT, even if we don't use those headers directly ourselves.

Additional context

The report was triggered by an ATLAS analyser complaining about this issue, with their own analysis code.

[eguiraud]

Thank you for the report Attila, I will take a look asap.

[amadio]

I agree that there is a problem, and it comes from the fact that you cannot easily depend on Vdt via targets when Vdt is builtin. CMake complains about headers in the interface which are in the build directory in that case, so a lot of workarounds are needed and no workaround works reliably across CMake versions. When I last touched this, we decided to use variables and rely on the fact that vdt headers were installed into the same place as ROOT headers when Vdt was builtin. However, when Vdt and ROOT are installed separately and into different locations, this doesn't work so well indeed. Fixing this is overdue, but we unfortunately have to keep it working for both builtin/external Vdt. I think that the solution proposed by @krasznaa is in the right direction.

[amadio]

See also https://sft.its.cern.ch/jira/browse/ROOT-9751

[eguiraud]

Reassigning to Bertrand as this is a more general build system issue than an issue with how libVecOps is set up (as I first assumed).

[amadio]

For anyone trying to fix this, please make sure to try with at least the earliest and latest supported CMake versions, and both for builtin/external Vdt. Maybe the situation improved with CMake 3.16 and above, but when I last touched this stuff, CMake was broken enough that I could not find a way not to do what I did by just using variables. To fix, one could try to revert commit a363eca referenced in the issue above, and try to fix the problem without getting rid of the Vdt::Vdt target.