[MacPorts] #57007: root6 port results in ambiguous include directories after 6.14

[MacPorts]

#57007: root6 port results in ambiguous include directories after 6.14
----------------------+--------------------
  Reporter:  olupton  |      Owner:  (none)
      Type:  defect   |     Status:  new
  Priority:  Normal   |  Milestone:
 Component:  ports    |    Version:  2.5.3
Resolution:           |   Keywords:
      Port:  root6    |
----------------------+--------------------
Description changed by olupton:

Old description:

> With the most recent verison(s) of the root6 port I have had problems
> compiling local code linking against ROOT.
>
> The problem seems to be that in the default MacPorts installation of
> root6 the ROOT headers are accessible both at
> `/opt/local/libexec/root6/include/root` (returned by `root-config
> --incdir`) and `/opt/local/include/root{,6}`
>
> And since 6.14 at least one header with the same name exists at multiple
> levels of the header file structure:
> {{{
> MD5 (/opt/local/libexec/root6/include/root/RConfig.h) =
> c2c2d44a3228fcbf9943048bfca2cb27
> MD5 (/opt/local/libexec/root6/include/root/ROOT/RConfig.h) =
> 5d2a7a998a363947acd947487a666bea
> }}}
>
> (see e.g. https://root.cern.ch/doc/v614/ROOT_2RConfig_8h.html and the
> non-existence of the same page for 6.12)
>
> When (automatically-generated) code tries to include the latter, i.e.
> `#include <ROOT/RConfig.h>`, then, if `/opt/local/include` is in the
> include path, `/opt/local/include/root/RConfig.h` is found instead (with
> a warning about non-portable filenames because the case doesn't match,
> -Wnonportable-include-path), and compilation fails because the wrong one
> of the two RConfig.h is picked up (errors like `error: use of undeclared
> identifier 'R__likely'` -- included so hopefully Google finds this
> ticket).
>
> A minimal workaround is to remove the `/opt/local/include/root{,6}`
> symlinks and make sure `/opt/local/libexec/root6/include/root` is in the
> include path for compilation. This seems a bit ugly, but so do all the
> other solutions...
>
> Possibilities I see:
> - Remove `/opt/local/include/root{,6}` symlinks: seems wrong to not have
> the headers somewhere under `/opt/local/include`
> - Move the headers one directory up the tree under `/opt/local/include`,
> i.e. `ln -s /opt/local/libexec/root6/include/root/RConfig.h
> /opt/local/include/RConfig.h` repeated for every ROOT header: involves a
> large number of links, but does integrate ROOT into the /opt/local tree a
> bit better.
> - Consider it a bug on my part that `/opt/local/include` is in the
> include path when compiling against ROOT: seems unreasonable, many other
> packages' headers are only available here.
> - Consider it a bug on my part that `/opt/local/include` comes before
> `/opt/local/libexec/root6/include` in the include path: doesn't seem very
> robust/reasonable to expect all external dependencies to respect this
> convention

New description:

 With the most recent verison(s) of the root6 port I have had problems
 compiling local code linking against ROOT.

 The problem seems to be that in the default MacPorts installation of root6
 the ROOT headers are accessible both at
 `/opt/local/libexec/root6/include/root` (returned by `root-config
 --incdir`) and `/opt/local/include/root{,6}`

 And since 6.14 at least one header with the same name exists at multiple
 levels of the header file structure:
 {{{
 MD5 (/opt/local/libexec/root6/include/root/RConfig.h) =
 c2c2d44a3228fcbf9943048bfca2cb27
 MD5 (/opt/local/libexec/root6/include/root/ROOT/RConfig.h) =
 5d2a7a998a363947acd947487a666bea
 }}}

 (see e.g. https://root.cern.ch/doc/v614/ROOT_2RConfig_8h.html and the non-
 existence of the same page for 6.12)

 When (automatically-generated) code tries to include the latter, i.e.
 `#include <ROOT/RConfig.h>`, then, if `/opt/local/include` is in the
 include path, `/opt/local/include/root/RConfig.h` is found instead (with a
 warning about non-portable filenames because the case doesn't match,
 -Wnonportable-include-path), and compilation fails because the wrong one
 of the two RConfig.h is picked up (errors like `error: use of undeclared
 identifier 'R__likely'` -- included so hopefully Google finds this
 ticket).

 A minimal workaround is to remove the `/opt/local/include/root` symlink
 and make sure `/opt/local/libexec/root6/include/root` is in the include
 path for compilation. This seems a bit ugly, but so do all the other
 solutions...

 It seems that the `/opt/local/include/root6` link always exists, but
 `/opt/local/include/root` depends on having run `port select root root6`.

 Possibilities I see:
 - Remove `/opt/local/include/root` symlink: seems wrong to not have the
 headers somewhere under `/opt/local/include`
 - Move the headers one directory up the tree under `/opt/local/include`,
 i.e. `ln -s /opt/local/libexec/root6/include/root/RConfig.h
 /opt/local/include/RConfig.h` repeated for every ROOT header: involves a
 large number of links, but does integrate ROOT into the /opt/local tree a
 bit better.
 - Consider it a bug on my part that `/opt/local/include` is in the include
 path when compiling against ROOT: seems unreasonable, many other packages'
 headers are only available here.
 - Consider it a bug on my part that `/opt/local/include` comes before
 `/opt/local/libexec/root6/include` in the include path: doesn't seem very
 robust/reasonable to expect all external dependencies to respect this
 convention

--

-- 
Ticket URL: <https://trac.macports.org/ticket/57007#comment:2>
MacPorts <https://www.macports.org/>
Ports system for macOS