Improve header file encapsulation

[vgvassilev]

Explain what you would like to see improved and how.

We should move all headers from $ROOTSYS/include to $ROOTSYS/ROOT/{component} and we should automatically generate wrapping headers that #include the relevant ROOT/ header with a deprecation warning.
Eg.

mv ROOTSYS/include/TLish.h ROOTSYS/include/ROOT/core/TLish.h
cat ROOTSYS/include/TLish.h

#warn "This forwarding header will go away in X please include \"ROOT/Base/TLish.h\" "
#include "ROOT/core/TLish.h"

The trampoline header file can be generated by our build system by adding a -DROOT_COMPATIBILITY switch that's on by default for few releases and then off.

ROOT version

master

Installation method

N/A

Operating system

N/A

Additional context

No response

[dpiparo]

Hi @vgvassilev could you please perhaps share a bit of the motivation you see behind this proposal, in other words the benefits for the project?

[vgvassilev]

Pretty much the same motivation of having new headers in ROOTSYS/include/ROOT. The upshot is that the third party codebase will become clearer of that TList.h is a ROOT thing; and more importantly we will define away a class of problems we have when installing ROOT. Right now on some systems we install everything in /usr/include, which is not a good practice unless one is libc.

[vgvassilev]

I remember @linev has made some progress in the past with this but then we were blocked by something wrt to modules that I do not remember...

[linev]

Some time ago we adjust cmake files so that when building ROOT libraries we using headers from source directories and not headers from $ROOTSYS/include. This makes dependencies between ROOT components more clear.

I just checked $ROOTSYS/include - there are 1476 files. And going this way we will double number of files.

[vgvassilev]

Yes, that is correct but only doubling them in count and during the deprecation phase.

[ferdymercury]

This seems a duplicate (or very similar to) of: https://its.cern.ch/jira/browse/ROOT-9403 so I'd suggest closing one or the other.

I am copying here the relevant discussion there:

When installing ROOT, we currently install all headers into /usr/include, e.g. /usr/include/TFile.h. However, as modules requires us to provide a modulemap for our headers which has the be in the same directory, we would have to place our ROOT modulemap in /usr/include/modulemodulemap. This leads to conflicts with all other system libraries, which also need to place a modulemap in /usr/include (libc being the prime example).

The solution would be to move all headers to /usr/include/ROOT. As we already have a ROOT subfolder in our installation, but it's only used by a few files, we have to do a small changes to our installation script:

All headers that are not currently in `/usr/include/ROOT` need to be installed in the `ROOT` subfolder.
All headers that are in `/usr/include/ROOT` should not be installed in `/usr/include/ROOT/ROOT`, but also in the normal `/usr/include/ROOT`. This requires some special code in CMake probably. This won't requires any code changes for users as they'll just find the same headers via the `/usr/include/` subdirectory now. The modulemap will handle this change fine as long as we remember to still specify the correct path in them (`ROOT/Header.h` -> `Header.h`).
The modulemap also needs to be installed in `/usr/include/ROOT` now.

This is definitely not fixed unless you make gnuinstall=ON by force and remove the option for gnuinstall=OFF (which is the current default, and also broken for other reasons, see e.g. ROOT-8589 and ROOT-9569). On the other hand, the severity is not so great to make it a full blocker, just making sure defaults don't cause big problems should be enough. And in your example, the header would end up in /opt/include/ROOT/ROOT/Foo.hxx, so it would be found.
comment - 17/Oct/19 11:34 AM

OK I misunderstood. Then this is not a blocker but an enhancement. I'm not even convinced it's a good one - it relies on the include dir being /usr/include/ROOT for this to work; if it's /opt/include/ROOT, "ROOT/Foo.hxx" will not be found at all because the canonical -I will be /opt/include/ROOT for such a ROOT install.

I.e. given that gnuinstall now installs into /usrl/include/root/ (which should really be /usr/include/ROOT!) I'd suggest to close this as fixed. Objections?
comment - 17/Oct/19 11:16 AM

Note that with -Dgnuinstall=ON the default is already to install headers into /include/root, but new headers go into /include/root/ROOT in that case. What Rafael suggests is somewhat different. As a workaround, one could enable gnuinstall and set CMAKE_INSTALL_INCLUDEDIR to something that won't conflict with other stuff installed into /usr. However, that won't solve the problem of different programs installing module.modulemap under different paths, and the wrong one being found first. This is probably what is the real blocker here. Cheers,