Re: Portability of GIR files

[Philip Chimento <philip chimento gmail com>]

On Wed, Mar 11, 2015 at 2:54 PM, Phil Clayton <phil clayton lineone net> wrote:

I've been assuming that GIR files are portable and using them to generate (equally) portable binding code.  I've found that they're not in one detail: the filename in the shared-library attribute looks to assume GNU ld.  For example:

  <namespace name="GObject"
             version="2.0"
             shared-library="libgobject-2.0.so.0"

On Mac OS X, I think we would have libgobject-2.0.0.dylib instead.

Can it be assumed (sometimes|mostly|always) that

  1. On GNU/Linux this name is the 'SO name' with form:
       <name>.so.<so-version>

  2. On Mac OS X this name has the form:
       <name>.<so-version>.dylib
?

On OSX the shared-library attribute has the full path to the librar(y/ies), including the .dylib extension:

shared-library="/path/to/lib/libgobject-2.0.0.dylib"

Here's the code that figures it out:

https://git.gnome.org/browse/gobject-introspection/tree/giscanner/shlibs.py#n55

It takes ldd output and outputs the full path in the case of OSX.

If that is always the case, could GIR files be made portable, e.g.
  <namespace ...>
    <shared-library name="gobject-2.0" so-version="0"/>
    ...
  </namespace>

Also, is there any other way in which GIR files are not fully portable?

I would not call this "unportable", but rather "installation-specific" in the same way that, for example, a pkg-config file is also "installation-specific".

--

Philip