[MacPorts] #62391: gobject-introspection 1.60.2_5: g-ir-scanner produces incorrect result for gdk-pixbuf2 build

[MacPorts]

#62391: gobject-introspection 1.60.2_5: g-ir-scanner produces incorrect result for
gdk-pixbuf2 build
--------------------+-----------------------------------
 Reporter:  VinDuv  |      Owner:  devans@…
     Type:  defect  |     Status:  assigned
 Priority:  Normal  |  Milestone:
Component:  ports   |    Version:  2.6.4
 Keywords:          |       Port:  gobject-introspection
--------------------+-----------------------------------
 On my High Sierra machine, building `gdk-pixbuf2` produces a `.gir` file
 (and associated `.typelib` file) with an incorrect library path:
 {{{
 $ grep shared-lib /opt/local/share/gir-1.0/GdkPixbuf-2.0.gir
              shared-library="./gdk-pixbuf/libgdk_pixbuf-2.0.0.dylib"
 }}}
 (instead of `/opt/local/lib/libgdk_pixbuf-2.0.0.dylib`). Strangely, the
 binary package gets it right.


 I’ve investigated why that happens and found some issues in `g-ir-
 scanner`:

 1. The `_link` method in `giscanner/dumper.py` (after modifications by
 patch `patch-fix-scanner-in-build-execution.diff`) merges library path
 lists by putting them in a set and converting them into a list. For
 instance:

 {{{
         self._options.library_paths = list (set().union
 (self._options.library_paths,
                                                          this_L))
 }}}

   The problem with this approach is that the resulting list will be in a
 random order, depending on the random hash seed chosen by the Python
 interpreter. One solution may be to use `sorted()` instead of `list()` to
 ensure an order on the resulting list. Note that this does not directly
 affects the `gdk-pixbuf2` build since the resulting path list is always
 `['./gdk-pixbuf']` in that case (the other path specified on the `g-ir-
 scanner` command line is in `LIBRARY_PATH` so it is removed).

 2. The same `_link` method directly modifies `options.library_paths`,
 which affects other parts of the program. I’m actually not sure if that’s
 by design or not. The consequence is that `giscanner/shlibs.py` code
 executes with `options.library_paths = ['./gdk-pixbuf']` instead of the
 original `['./gdk-pixbuf', '/opt/local/lib', '/opt/local/lib']`.

 3. In `giscanner/shlibs.py`, `_resolve_non_libtool` (as modified by patch
 `patch-fix-rpath-gir-typelib.diff`) tries to find the first path in
 `options.library_paths` that is not a build path, and assumes that it is
 the path where the libraries will be installed.

   Due to the previous issues, looking for the first path is fragile since
 `options.library_paths` will be in an unpredictable order; but in the case
 of the `gdk-pixbuf2`build, the issue is that this method does not handle
 relative paths: `./gdk-pixbuf` will be considered a non-build path, which
 is incorrect. The method should either normalize the library paths before
 before checking if they start with `os.getcwd()`, or assume that any
 relative path is a build path and skip it.

-- 
Ticket URL: <https://trac.macports.org/ticket/62391>
MacPorts <https://www.macports.org/>
Ports system for macOS