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

[cjones051073 (Chris Jones)]

Just using

#include <ROOT/RConfig.h>

in the wrapper is not a good idea, as that could in principle lead to cyclic dependencies, the include re-finding itself and going into a loop.

what about

#include_next <RConfig.h>

??

[cjones051073 (Chris Jones)]

One other idea. Could you try building MacPorts root without lines 253 and 254 in

​https://github.com/macports/macports-ports/blob/master/science/root6/Portfile

i.e., see if that hack is still needed or not ?

[olupton (Olli Lupton)]

If I remove the workaround then I am back to depending on the ordering of the include path as discussed in ​https://trac.macports.org/ticket/57007.

If /opt/local/include comes before /opt/local/libexec/root6/include/root then #include "RConfig.h" finds /opt/local/libexec/root6/include/root/RConfig.h, which is a forwarding header containing #include <ROOT/RConfig.h> that just re-includes itself thanks to /opt/local/include appearing first in the include path. Then compilation fails horribly because ROOT thinks it has included ROOT/RConfig.h but hasn't actually managed to.

If /opt/local/libexec/root6/include/root is earlier than /opt/local/include in the include path then it all works without workarounds (I also avoid the RVersion.h problem).

[cjones051073 (Chris Jones)]

I am starting to wonder if the best fix here is to remove from the 'port select' code the mirroring of the ROOT headers under /opt/local/include, so have /opt/local/libexec/root6/include/root the only place they are available. It can still install the sym-links so things like root, root-config are still available. As long as the user, as they should, uses root-config --incdir etc. to determine the correct paths, it should be transparent....

[olupton (Olli Lupton)]

That sounds reasonable to me (and I just tried it out locally). In that case the workaround in the Portfile can be removed again.

[cjones051073 (Chris Jones)]

OK, I have pushed an update that does this.

Note, you will need to, following updating your ports, manually disable/enable the port select, to pick up the change.

so

sudo port select root none
sudo port select root root6

[cjones051073 (Chris Jones)]

Going to close this as 'fixed'.. Oli, if you have any more issues please report back...

[olupton (Olli Lupton)]

I'm afraid that updating root_select and running the port select commands you gave hasn't worked.

sudo port select root none removes /opt/local/include/root, but sudo port select root root6 puts it back again.

[cjones051073 (Chris Jones)]

I can only guess you did not update properly, please try again. I've done it myself on two machines and it worked fine in both cases

Titan /opt/local/include > ls -lth root
ls: root: No such file or directory

[cjones051073 (Chris Jones)]

make sure you have these versions

Titan /opt/local/include > port installed root6 root_select
The following ports are currently installed:
  root6 @6.14.06_1+cocoa+cxx17+gcc8+graphviz+gsl+http+minuit2+opengl+python36+roofit+soversion+ssl+tmva+xml+xrootd (active)
  root_select @1.3_0 (active)

[olupton (Olli Lupton)]

Ah, sorry, I see the problem. I assumed the list of symlinks you modified was part of root_select, not root6, so it was enough to have root_select @1.3_0. But it actually seems to come from root6.

When I updated with your changes it didn't rebuild root6 because I'd already bumped the revision myself (to try removing the workaround... ​https://trac.macports.org/ticket/57654#comment:6).

Forcing a rebuild of root6 has fixed it. Sorry for the noise.