Re: Portability of GIR files

[Phil Clayton <phil clayton lineone net>]

13/03/15 19:43, Giovanni Campagna пишет:
> 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.

I'm generating bindings as source code for a statically-typed compiled 
language.  I'm hoping that I can do the work of factoring out what is 
platform-dependent in the GIR file and provide any required configure 
support.  Then others could generate bindings code on their machines 
(only) and deploy their applications (including that code) on all 
supported platforms.


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

Good to know, thanks.

Phil