Re: [Vala] Using Gir instead of vapi (and bug 624923)



في ح، 19-12-2010 عند 19:38 +0100 ، كتب Luca Bruno:
> On Sun, Dec 19, 2010 at 06:59:56PM +0100, Abderrahim Kitouni wrote:
> > I'm trying different ways of using a gir from vala : ideally, the
> > solution would be easily automated, and not break randomly.
> > 
> > 1. use vapigen to generate the vapi : with the addition of metadata
> > files, this is now possible, but given that my project has 2 namespaces
> > (and this 2 gir files), it doesn't work (or rather, I didn't find a way
> > to make it work). The only way I've found is to generate the vapi for
> > each file and concatenate them : not what I call easily automated.
> 
> It should work if you provide two .gir, in what sense "it doesn't work"?

I get duplicate symbol errors, as one depends on the other, the latter
is parsed twice (once as a dep and once because it's on the command
line).


> > 2. use the gir directly : valac does read metadata files, and thus is
> > able to use the gir directly. This works (except for bug 624923, see
> > below), but I have some questions :
> >   * Where does valac look for metadata files? (I know I can UTSL, but I
> > want a more definitive answer). Can those be installed somewhere so
> > everyone can use them? if so, where?
> 
> Actually in the same directory as the .gir. There's no plan to install
> metadata until we don't have any in the vala tree itself, at least for now.
> In the switch-to-gir branch there's a patch for --metadatadir option.
> >   * Is it a good idea to include (but not install) a metadata file for
> > gtk, to work around bugs? (such as 635287)
> 
> As said before, yes makes sense but as vala still uses .gi there's no plan
> for that yet.
I'm afraid this doesn't answer my question : I'm not really referring to
what is done in vala (and that's why I said this may be a user
question), I'm thinking about "my" project. Since it's easier to
understand when given the problem statement (rather than a partial
solution), here is the full story:

The project is Anjuta, it uses 2 namespaces : Anjuta (for handwritten
classes/interfaces) and IAnjuta (for generated interfaces), and
IAnjuta-3.0.gir depends on Anjuta-3.0.gir.

Trying to generate the vapi (after adding a IAnjuta-3.0.metadata to work
around of a typedef to gpointer that's unsupported now) :
   vapigen --library libanjuta-3.0 --pkg gtk+-3.0 --girdir . Anjuta-3.0.gir IAnjuta-3.0.gir
I get duplicate symbol errors (btw, I have a <package> element in my
Gtk-3.0.gir). And if I omit the girdir, I get either a "missing package
Anjuta-3.0" or the same error (depending on whether it was installed).
Generating the vapis for each namespace separately works ok.

Trying to compile the vala support plugin (which is written in vala),
using '--pkg IAnjuta-3.0' with a proper --girdir also works (when I
revert fc7fe82fbd0b19b6caaf, of course).

My questions are :
  1. Should I install the IAnjuta-3.0.metadata somewhere? (in the
girdir, or in some specified gir metadata dir), or is it better to
generate the vapi and install that? (taking in consideration that it's
painful to do that because of the above bug).
  2. Is it possible to include a Gtk-3.0.metadata in Anjuta to work
around the fact that I can't use neither Gtk-3.0.gir (because valac
doesn't like it ;-p) nor gtk+-3.0.vapi (because of bug 635287, valac
ends up parsing both).

> > I guess the bug should be reopened (or a new one opened) if there is a
> > problem with the patch.
> 
> Yes, please reopen it.
I don't have the right to, I'd have done it without asking otherwise ;-)

Regards,
Abderrahim



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]