Re: Portability of GIR files

[Phil Clayton <phil clayton lineone net>]

12/03/15 01:00, Giovanni Campagna wrote:
> 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
> > ?
> >
> > 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?
>
> GIR files depend on the expansion of the macros in the build
> environment, and include platform specific constants (eg. SIZEOF_VOID_P
> in GLib-2.0.gir or the values of Gio.IOErrorEnum / GLib.FileError which
> match errno numbers)
>
> So they are technically OS and arch specific.

Thanks Giovanni - I completely overlooked constant and enum values.

If I need any platform-dependent constants (and I'm hoping I don't 
because such platform-dependent capability should be in the target 
language's basis library) it seems I will have to expand the macros 
during the installation configuration for my binding lib.  Arguably I 
should be doing that anyway.

For enum consts, I think C99 specifies (for once!) what values you get. 
 After a quick look at the code, I couldn't see how GIOErrorEnum or 
GFileError enum values are platform-dependent.  In fact, would 
preprocessor directives in or around an enum typedef confuse 
g-ir-scanner?  I'm not too familiar with the inner workings...

Phil