[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:4 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.

 It doesn't oblige port maintainers to do anything other than report
 problems to the developers of the software. It's up to the developers of
 the software to fix their broken build systems. If developers do not
 comply, then port maintainers can be nice and try to fix it themselves,
 but they don't have to go to that trouble. They can allow the port to be
 broken in these situations, and refer users who encounter the problem to
 the developers; perhaps that motivates the developers to finally fix it.

 You presuppose that this problem is unique to the Mac or unique to
 MacPorts. I claim it is not.

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

 Which is why I pointed out my longstanding suggestion that base should use
 `-isystem` instead of `-I`.

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

 If a developer requires that, then that port might well fail to build in
 MacPorts, unless trace mode is used.

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

 That is ''not'' a requirement for my proposal to succeed. If
 `-isystem/opt/local/include` is added to the flags, then
 /opt/local/include will be considered a system location, and will be
 checked after project locations, ''even if'' `-I/opt/local/include` also
 appears. So, for a concrete example, if the compile line includes in order
 the flags `-isystem/opt/local/include -I/opt/local/include
 -Isome/local/path`, then the paths checked, in order, will be
 some/local/path and then /opt/local/include.

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

 glib2 currently patches configure to enable universal building, because
 patching configure.ac would involve running autoreconf which would require
 pkgconfig which we were trying to avoid. If we're no longer trying to
 avoid that, then we would patch configure.ac instead of configure.

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

 Yes, /opt/local/include/glib-2.0/glib/gi18n.h and
 /opt/local/include/glib-2.0/glib/gi18n-lib.h still `#include <libintl.h>`.

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

 I don't see why we would do that. If you think gettext should do that,
 then I suppose you think all other ports that currently put things
 directly in /opt/local/include should do that, and I don't think we're
 going to make all those changes, and the consequent necessary changes in
 all the ports that use those ports, all to accommodate broken build
 systems. Fix the broken build systems instead.

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

 You're right that an absolute path in the `#include` statement should
 work. I hadn't thought about that, so let me think about it and try it out
 and see if there are any adverse consequences of making that change.

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