[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 RJVB):

 Replying to [comment:3 ryandesign]:

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

 I must not have been clear. This approach would ultimately oblige port
 maintainers to plow through the build system trying to figure out how to
 split the sources of the -I flags and then patch the system so that those
 flags are placed in what MacPorts thinks is the correct order.
 Nobody is perfect, but if builds succeed everywhere except in a certain
 build/packaging/distribution system, guess where the blame will be put.

 I maintain that the proper fix is to avoid the problem as far as possible.

 Note how big and complex build systems (think Qt and KF5) now generate
 enormous compiler commands because every (sub)component puts its
 headerfiles in dedicated subdirectories that are then listed explicitly
 with as many -I flags, while the code is supposed just to do `#include
 <foo.h>`.

 Also keep in mind that many complex projects are designed with the idea in
 mind that they should be built in a clean environment, like the build bots
 but also their CI systems do. That affects mostly issues that arise when
 building a new version with the old version already installed in the
 target location, but it's not too much of a stretch for them to expect
 users to remove at least the dev files of conflicting packages.

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

 I know, and that's exactly what I meant. For /usr/local/include this
 cannot be avoided, but it can for ${prefix}/include .

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

 Again, only as far as it's caused by base. I doubt that the pcre build
 system is clever enough NOT to add ${prefix}/include to its required
 cflags when base starts adding that path via -isystem.

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

 DIdn't say it was, don't know how necessary it is (to set CPATH) either,
 and this is easy to undo in the Portfiles that require it.

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

 You can rather safely exclude all those that use CMake, and for the
 remainder do a quick `grep -i 'pkg.*pcre' -R ${worksrcpath}
 --include="*.ac"` to exclude the ones that clearly do use pkg-config to
 find the dependency. Of course one can install a few symlinks to expose
 the headerfiles in ${prefix}/include if you really want to be sure no
 ports will break. But I'd say this should break as much as a regular
 upgrade of the dependency would, and could be treated as such.

 In the end it will be the pcre maintainer who decides - or the pcre
 developers could agree that nowadays it's better to put their headers in
 their own directory O:-)

 > That's not particularly the type of patch I was expecting.

 Evidently it's the patch that I tested, which changes as little as
 possible.

 Why would it be necessary to patch configure.ac?

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

 That is no longer unambiguously clear from the current comments above the
 patches. Is it still true?

 >  The developers of Qt have said that
 [https://bugreports.qt.io/browse/QTBUG-34902 we should not be doing that],

 I got very similar reactions ("the package is broken. .pc files must not
 ever list system paths.") to my query on their ML. I agree with that
 guideline, and thus plan to take this point up with the pcre developers.

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

 First thing would be to check if a solution is still required. I've
 rebuilt a few ports with the patched glib-2.0.pc file without problem, but
 not enough yet to be confident that there's no longer a reason to add a
 specific -I for libintl.h

 Another solution to use would be to put libintl.h and family in their own
 directory too.

 Then there's the easy solution: patch the #include statement of the
 file(s) that can't find libintl.h . Maybe use an absolute include path
 (`#include </opt/local/include/libintl.h>`); I don't think I ever tried
 doing that but if it works it should have less potential side-effects than
 the .pc file tweak. Or do `ln -s ../libintl.h ${prefix}/include/glib-2.0
 /glib-libintl.h` and include that file instead.

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