root6 port has header problems in 6.14/06

[olupton (Olli Lupton)]

It seems that there is a problem with the include paths in the newest (6.14/06) version of ROOT.

This is closely related to ​https://trac.macports.org/ticket/57007 -- the resolution to that was to make /opt/local/libexec/root6/include/root/RConfig.h a symbolic link to /opt/local/libexec/root6/include/root/ROOT/RConfig.h.

The new problem is that /opt/local/libexec/root6/include/root/ROOT/RConfig.h now contains #include "../RVersion.h", which is intended to resolve to /opt/local/libexec/root6/include/root/RVersion.h. If the include path is such that #include "RConfig.h" picks up the symbolic link then compilation fails:

/opt/local/libexec/root6/include/root/RConfig.h:22:10: fatal error: '../RVersion.h' file not found
#include "../RVersion.h"
         ^~~~~~~~~~~~~~~
1 error generated.

This change to RConfig.h was introduced in ​https://github.com/root-project/root/commit/38580d360a3c1793e5cc8af1c9e9efbba71f9b74#diff-9361ac3923df05c6c743e0822e6fe33e

Reverting the change, so RConfig.h contains #include "RVersion.h", worked for me as a temporary hack. I don't immediately see a nice solution...

[cjones051073 (Chris Jones)]

The ROOT devs are really going out of their way to make this difficult...

Frankly, I view this as a flaw in the way the package their headers upstream, its a real spagetti mess right now.

Maybe though, there is something you could try. Could you remove the sym link

/opt/local/libexec/root6/include/root/RConfig.h

and instead make it a wrapper header that has in it just

#include_next <ROOT/RConfig.h>

and see how things fair with that ?

[olupton (Olli Lupton)]

That didn't work:

ccache /opt/local/bin/clang++  -DCustomRoot_EXPORTS -DR__HAVE_CONFIG -DWITH_TBB -Iinclude -isystem explicit/include -isystem range-v3/include -isystem /opt/local/libexec/root6/include/root -isystem /opt/local/include -pipe -Os -stdlib=libc++ -m64 -pipe -fsigned-char -fno-common -Qunused-arguments -pthread -std=c++1z -stdlib=libc++ -DR__HAVE_CONFIG -O2 -g -DNDEBUG -fPIC   -Wall -Weverything -pedantic -Wno-c++98-compat -Wno-c++98-compat-pedantic -Wno-missing-prototypes -Wno-global-constructors -Wno-padded -Wno-conversion -Wno-double-promotion -Wno-weak-vtables -Wno-exit-time-destructors -Wno-float-equal -Wno-used-but-marked-unused -Wno-undefined-func-template -std=c++17 -Wno-old-style-cast -Wno-unused-macros -Wno-reserved-id-macro -Wno-zero-as-null-pointer-constant -MD -MT src/CMakeFiles/CustomRoot.dir/CustomRootDicts.cxx.o -MF src/CMakeFiles/CustomRoot.dir/CustomRootDicts.cxx.o.d -o src/CMakeFiles/CustomRoot.dir/CustomRootDicts.cxx.o -c src/CustomRootDicts.cxx
In file included from src/CustomRootDicts.cxx:12:
In file included from /opt/local/include/ROOT/RConfig.h:1:
/opt/local/include/ROOT/RConfig.h:1:15: fatal error: 'ROOT/RConfig.h' file not found
#include_next <ROOT/RConfig.h>
              ^~~~~~~~~~~~~~~~
1 error generated.

I think the original #include "RConfig.h" finds /opt/local/libexec/root6/include/root/RConfig.h (contents: #include_next), which then looks for ROOT/RConfig.h starting from the next directory in the include search list (/opt/local/include) and finds /opt/local/include/root/RConfig.h...which is the same file containing #include_next. But 2nd time there are no more search paths to try, so it fails.

If I use #include instead of #include_next in the wrapper header then my current test case compiles. Not sure if that will break in some other case though...