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

[MacPorts]

#44395: glib2, glib2-devel: don't add -I${prefix}/include to glib-2.0.pc
--------------------------------+------------------------
  Reporter:  ryandesign         |      Owner:  ryandesign
      Type:  defect             |     Status:  new
  Priority:  Normal             |  Milestone:
 Component:  ports              |    Version:  2.3.1
Resolution:                     |   Keywords:
      Port:  glib2 glib2-devel  |
--------------------------------+------------------------

Comment (by RJVB):

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

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