Re: where to find GIR XML documentation?
- From: Tony Houghton <h realh co uk>
- To: Emmanuele Bassi <ebassi gmail com>
- Cc: "Jasper St. Pierre" <jstpierre mecheye net>, Tony Houghton <h realh co uk>, gir-devel-list gnome org
- Subject: Re: where to find GIR XML documentation?
- Date: Tue, 19 Feb 2019 18:37:07 +0000
I don't think parsing the gir XML to generate static-typed bindings is easier than using the typelib API. Although it doesn't use GObject, it is introspected, so it can be used from python etc. Some important information is awkward to extract from the XML, and the API has methods that make it easier. The trouble is, without being able to get a typename from a GITypeInfo associated with an argument or return value the API isn't much use for languages with strict typing. Or is it possible to get a typename by using g_base_info_get_attribute()?
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.
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.
On Tue, Feb 19, 2019 at 5:38 AM Tony Houghton <
h realh 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).
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.
--
gir-devel-list mailing list
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
https://mail.gnome.org/mailman/listinfo/gir-devel-list
--
--
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]
