glib2, glib2-devel: don't add -I${prefix}/include to glib-2.0.pc

[ryandesign (Ryan Carsten Schmidt)]

MacPorts patches glib's glib-2.0.pc file to add -I${prefix}/include to Cflags, ever since r18645 which was done to fix #9937. But the developers of ​Qt have declared that it is ​broken for us to be making this change, so I plan to revert it.

[cooljeanius (Eric Gallager)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

The Qt bug report's URL has changed and is now ​https://bugreports.qt.io/browse/QTBUG-34902

The Qt developer's complaint is that a .pc file should not contain -I${prefix}/include. But tons of other MacPorts-installed .pc files do, and why shouldn't they? That's exactly what .pc files are for: to provide the flags necessary to compile something.

[RJVB (René Bertin)]

The exact claim is that .pc files should never contain system paths and there's something to say for that. It may also be an official guideline.

As suggested on #55577, system paths should come last (or be declared via -isystem). You cannot guarantee that this will be possible if any number of dependencies insert their -I options possibly mixed with other compiler options. The build system cannot know which of those -I's point to what it should consider as system paths so even if it could and wanted to rearrange all those options it still lacks the information required to do it properly.

That's exactly what .pc files are for: to provide the flags necessary to compile something.

Evidently, but it's the responsibility of the person packaging that "something" to ascertain that it's installed appropriately and the .pc provide flags that work without causing interference. Many projects install their headers in /usr/include (or /usr/local/include) because that's the easy solution: no need to declare any header search paths and it's still possible to override the system version (= let the compiler include alternative headers). That approach clearly has its limits when the prefix isn't / or /usr/local, and I for one now understand better why more and more projects have been using their own header directory. (= Not just to keep /usr/include tidy and cleaner).

Edit: is this patch still necessary? It was introduced over 10y ago, a lot of code has flowed under and through the north, south etc. bridges ;)

[ryandesign (Ryan Carsten Schmidt)]

Yes, the problem the patch solves (gi18n.h uses #include <libintl.h> so the path to libintl.h needs to be provided in the compile flags; see #9937) is still relevant; see comment:ticket:55577:3.

comment:ticket:55577:4 suggests an alternate fix for the problem: instead of adding -I/opt/local/include to Cflags in glib-2.0.pc, patch the two files that #include <libintl.h> to so that they #include </opt/local/include/libintl.h> instead. While disagreeing with the premise that ports should not use -I/opt/local/include or provide .pc files that do so, I'm willing to make this change because it is a less invasive solution to the problem.

[ryandesign (Ryan Carsten Schmidt)]

In e302b20bdd71e9e16b142c525d8d809ee56ffd05/macports-ports:

glib2, glib2-devel: No longer add -I/opt/local/include to glib-2.0.pc

This had originally been added so that other software could include
gi18n.h without error, since gi18n.h uses #include <libintl.h> so
the path to libintl.h needs to be among the include paths.

MacPorts already puts -I/opt/local/include into CPPFLAGS during the
configure phase so I expected this change not to affect most ports, and
to merely help the very few ports that either ignore CPPFLAGS or don't
use a configure script but do use pkg-config.

See: #9937

But some build systems do not put the -I flags into the correct order,
and are so complicated that fixing that is nearly impossible (e.g. Qt).
If -I/opt/local/include appears in the compiler flags, such ports may
fail to upgrade to a new version if the previous version is active, as
old include files from the old version are mistakenly used instead of
the new versions. Such ports may clear the automatically-added CPPFLAGS
to avoid the appearance of -I/opt/local/include, but if they depend on
glib2, that flag would reappear.

Therefore, don't add -I/opt/local/include to glib-2.0.pc, and instead
patch the files that #include <libintl.h> to do so by absolute path.

Closes: #44395