Repository navigation
[Build system] ROOT installs its builtins directly into CMAKE_INSTALL_PREFIX. #8655
Description
- Checked for duplicates
Describe the bug
When you install a ROOT with builtins, it also installs the builtin headers (+ libraries probably) into the system directory.
This might be at least surprising, if not annoying.
Expected behavior
If builtins are needed, they could go into ${CMAKE_INSTALL_PREFIX}/include/ROOT_builtins} or similar.
This unfortunately requires going through all builtins, and changing their install locations, but I don't see a way around that.
To Reproduce
cmake -DCMAKE_INSTALL_PREFIX=/tmp/dummyInstallation <path/to/root>
make -j install
Setup
Master, linux.
Metadata
Metadata
Type
Projects
- Status
Activity
eguiraud commentedon Apr 4, 2023
The headers of a builtin nlohmann/json are installed at
${CMAKE_INSTALL_PREFIX}/include/nlohmann, which (as far as installing third-party stuff goes) is probably ok?Or you would rather have ROOT install those headers at
${CMAKE_INSTALL_PREFIX}/include/ROOT_builtins/nlohmann? If this was the case, projects building against ROOT would not find the builtins anymore, at least not without extra care.hageboeck commentedon Apr 4, 2023
I guess the question is whether ROOT should interfere with what you installed in your system. Let's say you have something installed in
/usr/include/nlohmann. Now you install ROOT, and for some reason it came with a builtin nlohmann_json (e.g. because of a different version). Now, everything in your system that was relying on the original nlohman_json version is broken.I thought that as far as reasonably possible, ROOT should not interfere with what you install in your system (i.e. it should leave all headers and libraries untouched), unless they are ROOT's own headers/libraries?
You are correct that projects building against that installed ROOT would need to know about the include location, but I would think that this is ROOT's job (by exporting CMake targets such as ROOT::nlohmann).
Maybe that's what users expect of ROOT, but I was at least surprised to have stuff installed that I didn't ask for.
Let me rephrase this, maybe:
You install X from source. Would you expect that this also installs Y, and possibly overwrites / corrupts any existing Ys?
hageboeck commentedon Jul 29, 2026
Tested today with all builtins on. Removed all files that match
Roo*.handT[A-Z]*.h. This results in:Particularly bad are probably:
Also generic headers like:
Match.h,Buttons.h,Compression.h[builtins] Install builtin vdt headers in ROOT/builtins/vdt.
[builtins] Don't install headers of a builtin XRootD.
[builtins] Install builtin vdt headers in ROOT/builtins/vdt.
[builtins] Install builtin vdt headers in ROOT/builtins/vdt.
ferdymercury commentedon Sep 16, 2026
The original issue is now solved thanks to Stephan. Builtins are private links so headers are not installed.
The side observations (zipLzma, strlcpy, riostream, etc) are under deprecation and will be removed soon.
Buttons.h or Match.h are very generic, but even if not, Debian won't be happy with adding 2000 headers without ROOT prefix so a different approach is being investigated that changes install prefix
[math] Rename header to be pattern-conforming and deprecate old one.
[builtins] Don't install headers of a builtin XRootD.
[math] Rename header to be pattern-conforming and deprecate old one.