[MacPorts] #57654: root6 port has header problems in 6.14/06

[MacPorts]

#57654: root6 port has header problems in 6.14/06
---------------------+--------------------
Reporter: olupton | Owner: (none)
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version: 2.5.4
Keywords: | Port: root6
---------------------+--------------------
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...

[MacPorts]

#57654: root6 port has header problems in 6.14/06
----------------------+--------------------
Reporter: olupton | Owner: (none)
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version: 2.5.4
Resolution: | Keywords:
Port: root6 |
----------------------+--------------------

Comment (by cjones051073):

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 ?

[MacPorts]

#57654: root6 port has header problems in 6.14/06
----------------------+--------------------
Reporter: olupton | Owner: (none)
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version: 2.5.4
Resolution: | Keywords:
Port: root6 |
----------------------+--------------------

Post by MacPorts
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
{{{
'../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...

New description:

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

--

Comment (by olupton):

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

[MacPorts]

#57654: root6 port has header problems in 6.14/06
----------------------+--------------------
Reporter: olupton | Owner: (none)
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version: 2.5.4
Resolution: | Keywords:
Port: root6 |
----------------------+--------------------

Comment (by cjones051073):

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

??

[MacPorts]

#57654: root6 port has header problems in 6.14/06
----------------------+--------------------
Reporter: olupton | Owner: (none)
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version: 2.5.4
Resolution: | Keywords:
Port: root6 |
----------------------+--------------------

Comment (by cjones051073):

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 ?

[MacPorts]

#57654: root6 port has header problems in 6.14/06
----------------------+--------------------------
Reporter: olupton | Owner: cjones051073
Type: defect | Status: assigned
Priority: Normal | Milestone:
Component: ports | Version: 2.5.4
Resolution: | Keywords:
Port: root6 |
----------------------+--------------------------
Changes (by mf2k):

* owner: (none) => cjones051073
* status: new => assigned
* cc: cjones051073 (removed)

[MacPorts]

#57654: root6 port has header problems in 6.14/06
----------------------+--------------------------
Reporter: olupton | Owner: cjones051073
Type: defect | Status: assigned
Priority: Normal | Milestone:
Component: ports | Version: 2.5.4
Resolution: | Keywords:
Port: root6 |
----------------------+--------------------------

Comment (by olupton):

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

[MacPorts]

#57654: root6 port has header problems in 6.14/06
----------------------+--------------------------
Reporter: olupton | Owner: cjones051073
Type: defect | Status: assigned
Priority: Normal | Milestone:
Component: ports | Version: 2.5.4
Resolution: | Keywords:
Port: root6 |
----------------------+--------------------------

Comment (by cjones051073):

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

[MacPorts]

#57654: root6 port has header problems in 6.14/06
----------------------+--------------------------
Reporter: olupton | Owner: cjones051073
Type: defect | Status: assigned
Priority: Normal | Milestone:
Component: ports | Version: 2.5.4
Resolution: | Keywords:
Port: root6 |
----------------------+--------------------------

Comment (by olupton):

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

[MacPorts]

#57654: root6 port has header problems in 6.14/06
----------------------+--------------------------
Reporter: olupton | Owner: cjones051073
Type: defect | Status: assigned
Priority: Normal | Milestone:
Component: ports | Version: 2.5.4
Resolution: | Keywords:
Port: root6 |
----------------------+--------------------------

Comment (by cjones051073):

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

[MacPorts]

#57654: root6 port has header problems in 6.14/06
----------------------+--------------------------
Reporter: olupton | Owner: cjones051073
Type: defect | Status: assigned
Priority: Normal | Milestone:
Component: ports | Version: 2.5.4
Resolution: | Keywords:
Port: root6 |
----------------------+--------------------------

Comment (by cjones051073):

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

[MacPorts]

#57654: root6 port has header problems in 6.14/06
----------------------+--------------------------
Reporter: olupton | Owner: cjones051073
Type: defect | Status: closed
Priority: Normal | Milestone:
Component: ports | Version: 2.5.4
Resolution: fixed | Keywords:
Port: root6 |
----------------------+--------------------------
Changes (by cjones051073):

* status: assigned => closed
* resolution: => fixed

[MacPorts]

#57654: root6 port has header problems in 6.14/06
----------------------+--------------------------
Reporter: olupton | Owner: cjones051073
Type: defect | Status: reopened
Priority: Normal | Milestone:
Component: ports | Version: 2.5.4
Resolution: | Keywords:
Port: root6 |
----------------------+--------------------------
Changes (by olupton):

* status: closed => reopened
* resolution: fixed =>


Comment:

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.

[MacPorts]

#57654: root6 port has header problems in 6.14/06
----------------------+--------------------------
Reporter: olupton | Owner: cjones051073
Type: defect | Status: reopened
Priority: Normal | Milestone:
Component: ports | Version: 2.5.4
Resolution: | Keywords:
Port: root6 |
----------------------+--------------------------

Comment (by cjones051073):

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

[MacPorts]

#57654: root6 port has header problems in 6.14/06
----------------------+--------------------------
Reporter: olupton | Owner: cjones051073
Type: defect | Status: reopened
Priority: Normal | Milestone:
Component: ports | Version: 2.5.4
Resolution: | Keywords:
Port: root6 |
----------------------+--------------------------

Comment (by cjones051073):

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)
}}}

[MacPorts]

#57654: root6 port has header problems in 6.14/06
----------------------+--------------------------
Reporter: olupton | Owner: cjones051073
Type: defect | Status: reopened
Priority: Normal | Milestone:
Component: ports | Version: 2.5.4
Resolution: | Keywords:
Port: root6 |
----------------------+--------------------------

Comment (by olupton):

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.