[MacPorts] #55577: getting rid of unforeseen -I${prefix}/include option adding and its potential side-effects

[MacPorts]

#55577: getting rid of unforeseen -I${prefix}/include option adding and its
potential side-effects
--------------------------+-----------------
  Reporter:  RJVB         |      Owner:
      Type:  enhancement  |     Status:  new
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:
Resolution:               |   Keywords:
      Port:  pcre, glib2  |
--------------------------+-----------------

Comment (by ryandesign):

 Replying to [comment:2 RJVB]:
 > Replying to [comment:1 ryandesign]:
 >
 > > Sounds like a bug in that project. It should place the appropriate
 `-I` flags for including its own headers ''before'' the `-I` flags from
 pkg-config and elsewhere that include the system headers.
 >
 > That's what I thought first too, but after checking with them (Qt) it
 turned out the issue was in my build environment. Even if -I options work
 that way it's not very reliable because when projects get more complex you
 do not always keep full control over the order in which you're assembling
 them, nor over which replies from pkg-config contain -I flags that should
 go all at the end. (FWIW, the conflict arose deep in the QtWebEngine build
 tree.)

 MacPorts policy has been that it is the responsibility of the build system
 to put the `-I` flags in the correct order. Sometimes, for complex build
 systems, it's not easy to fix such problems, but we still maintain that
 that is the best fix.

 > That's also why we have such problems avoiding interference from
 /usr/local/include.

 Build systems that add flags for using /usr/local are certainly a problem
 and they should be told not to do that in MacPorts. But that's not why
 /usr/local is a problem for MacPorts. Rather, it's that compilers look in
 /usr/local/include and /usr/local/lib by default, even when there is no
 corresponding `-I` or `-L` flag. See wiki:FAQ#usrlocal.

 > > Switching MacPorts base to using `-isystem` instead of `-I` would be
 another possible solution to this problem which is proposed in #40656.
 >
 > base is not to blame here (beyond possibly the fact it sets CPATH).

 I didn't say base was to blame, I said making that change in base would be
 a solution to the problem.

 Setting `CPATH` (and `LIBRARY_PATH`) is not a bug, but a feature.

 > > > This change will be reflected in the pcre/pcre2 pkg-config files.
 > >
 > > This has the potential to break ports that use pcre/pcre2. Probably
 not all of them use pkg-config.
 >
 > That would be a bug in those ports, easily fixable (if they don't use
 pkg-config they already must be told where to find the header directory).
 And easy to check for in MacPorts (revbump all dependents).

 Not that easy to check for, since someone would need to look through the
 logs of all the failed builds, and then fix them. Probably not all of the
 failed builds will be because of pcre. I count 131 ports depending on pcre
 or pcre2.

 > > I'm tentatively ok with changing glib2/glib2-devel back to using pkg-
 config.
 >
 > I haven't tried and so cannot guarantee that this will indeed be
 sufficient to take glib2 out of the equation here. All I know is that
 `pkg-config --cflags glib-2.0` includes the result for `pkg-config
 --cflags pcre`.
 >
 > I didn't get around to attaching the glib2 patch, will do so now.

 That's not particularly the type of patch I was expecting. I was expecting
 a patch that adds the pkgconfig build dependency, removes the environment
 variables that tell the configure script not to use pkg-config and specify
 the custom flags, removes the custom code from the pre-configure block for
 reading libffi's pkg-config file, and reworks the patchfiles to patch
 configure.ac instead of configure and runs autogen.sh, since the only
 reason we weren't running autogen.sh is that that would require pkg-
 config.

 I should point out though that the reason why `-I${prefix}/include` is in
 the .pc file is ''not'' because of pcre but because of libintl; see #9937.
 The developers of Qt have said that
 [https://bugreports.qt.io/browse/QTBUG-34902 we should not be doing that],
 and I filed #44395 about undoing it, but looking at it again now, the Qt
 developer did not give a justification that I find satisfactory, and I'm
 not sure what other solution we could use.

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