GNOME.org
 

Re: where to find GIR XML documentation?

In my experience, TYPELIB files are not suitable for generating a static library because they are too platform-specific: for efficiency, information has been resolved for the particular platform, e.g. 
1. The sizes of structs and offsets of fields are hard-coded.
2. There are no platform-dependent types like int and long int - these have been resolved to int32, int64 etc. Thus any library generated from TYPELIB would need different versions for x86 and x86_64. Also, as a result of resolving types: 
3. There are no alias types.
It's tempting to use girepository because you can get started quickly, it gives you most of what you want and you don't have to work out the default values, support moved-to and shadows attributes, etc. Unfortunately, after investing a lot of effort, you'll find that you really should have started off working from GIR files. I ended up generalizing my GIRepository interface for GIR files to re-use most of what I'd done.
There are other little things that make TYPELIBs less suitable. If your bindings involve any C function wrappers, it's nicer to be able to use the C type strings to benefit from compiler checks on C types. Also, you can't generate two versions of the same library (e.g. vte-2.90 and vte-2.91) from the same session because girepository can only load one version. These are minor things but the underlying issue is that the goals of TYPELIB aren't aligned with the needs of generating a static library. 

Phil


On 19/02/19 17:12, Emmanuele Bassi via gir-devel-list wrote:
The typelib is just as an intermediate format as the GIR; it only makes sense under the semantics of the particular language that uses libgirepository, and it exists only because loading XML every time you load an application written with a non-C language is an unacceptable performance penalty.
Improving the typelib is basically pointless for non-dynamic languages; parsing the GIR and querying the binary blob—which, by its own design, does not represent the extracted GIR data 1:1—in order to generate code is basically the same operation, except it's easier to parse XML than it is to use libgirepository's C API.
Stabilising and formalising the GIR format is a better effort, at this point; the typelib binary blob generated by g-ir-compiler would benefit from that effort just as well as any tool that does code generation starting from the XML. 

Ciao,
  Emmanuele.
On Tue, 19 Feb 2019 at 16:48, Jasper St. Pierre <jstpierre mecheye net <mailto:jstpierre mecheye net>> wrote: 

    Hi,

    Unfortunately, the GIR XML is basically an intermediate product, and
    unless you implement the same algorithms as the GIR typelib
    compiler, you won't end up matching the same semantics. You can see
    this in places where we count the number of '*' characters in the
    c:type as a heuristic [0]. I don't think anybody would be against
    improving the GIR XML to make things more high-level and have more
    meaningful semantics, but I think improving the typelib is going to
    be more fruitful, since it comes after all the processing that the
    GIR compiler also does.

    [0]
    https://gitlab.gnome.org/GNOME/gobject-introspection/blob/master/girepository/girparser.c#L2034

    On Tue, Feb 19, 2019 at 5:38 AM Tony Houghton <h realh co uk
    <mailto:h realh co uk>> wrote:


        On Tue, 19 Feb 2019 at 09:40, Philip Withnall
        <philip tecnocode co uk <mailto:philip tecnocode co uk>> wrote:

            On Tue, 2019-02-19 at 17:26 +1100, David Bellot via
            gir-devel-list wrote:

            Hi,

            I'm looking for a complete description of the GIR xml
            format. The website is a bit outdated and misses a lot of
            documentation (or at least it's my impression).


            https://developer.gnome.org/gi/stable/gi-gir-reference.html
            is the best I know of, but it’s pretty thin and you probably
            found it in the docs/ directory instead.


        https://developer.gnome.org/gi/stable/index.html and
        https://wiki.gnome.org/Projects/GObjectIntrospection/Annotations
        are helpful for summarising what sort of information should be
        available in each type of node, but unfortunately there's no
        direct mapping between the three types of representation.

            Why do you need a description of the XML format? Typically,
            using the GIR utilities means you don’t need to know the XML
            format.


        Parsing the XML seems to be the only way to generate good
        quality static definitions for a typesafe language eg Java,
        Kotlin, Typescript. For a start there are a few useful immediate
        children of the root node that you can't read with the typelib
        API (eg C headers, pkg-config package name). But most of all,
        GITypeInfo doesn't contain a type name (calling
        g_base_inf_get_name() on a GITypeInfo causes an abort!). So any
        function definitions in the target language would have argument
        and return types limited to primitive types, opaque pointers,
        generic GObjects and other generic boxed types.
-- TH 

        _______________________________________________
        gir-devel-list mailing list
        gir-devel-list gnome org <mailto:gir-devel-list gnome org>
        https://mail.gnome.org/mailman/listinfo/gir-devel-list
--   Jasper 
    _______________________________________________
    gir-devel-list mailing list
    gir-devel-list gnome org <mailto:gir-devel-list gnome org>
    https://mail.gnome.org/mailman/listinfo/gir-devel-list



--
https://www.bassi.io
[@] ebassi [@gmail.com <http://gmail.com>]


_______________________________________________
gir-devel-list mailing list
gir-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/gir-devel-list
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]