Re: Portability of GIR files

[Giovanni Campagna <scampa giovanni gmail com>]

On Fri, Mar 13, 2015 at 12:29 PM, Phil Clayton 
<phil clayton lineone net> wrote:
> 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.

Well, it depends on the language. If you're generating bindings for a 
compiled language, you will need to use platform and arch specific gir 
files. If you're generating bindings for a dynamic language, you can 
lookup the constants at runtime from the typelib. Java, C# and the like 
are probably in between: you can use the gir to generate a platform 
agnostic class file, and then have the real app link to the real class 
file with the good values.

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

Sorry, I was mistaken about GIOErrorEnum / GFileError. The one with 
platform constant is GIOCondition, which is defined to be identical to 
POLLIN / POLLOUT / POLLERR / etc.
A quick grep for SYSDEF reveals also GSocketFamily and GSocketMsgFlags 
in gio.
Interestingly, win32 has the same values for POLL* and MSG_* as Linux, 
so maybe it doesn't matter.

Preprocessor directives in an enum work just fine: the preprocessor is 
run before parsing the file, so g-ir-scanner only sees the numbers.

Cheers

Giovanni