Re: [Vala] Binding problem or ClutterGst problem or my problem?

[Brian Duffy <brduffy gmail com>]

Interesting. I wonder, does Vala mention in their notes for new releases on
the web site if they are updating a specific vapi file? How could I go
about finding out what version of clutter (for instance) that Vala's
release of the clutter vapi file supports? Is it in the name of the vapi
file (something like clutter-1.8-vapi)? If not, would looking for a file
modification date that I can compare to clutter release dates make sense.
It would be nice to know up front what version of a specific library my
default Vala vapi supports. At some point I guess I'll have to start
understanding how vapi files work but for now I have enough to do just
getting up to speed on Vala and Clutter, which by the way is the most fun I
have had programming in quite some time.

thnx

Brian

On Fri, Jan 13, 2012 at 3:50 PM, Evan Nemerson <evan coeus-group com> wrote:

> On Fri, 2012-01-13 at 17:46 +0000, Emmanuele Bassi wrote:
> > On 2012-01-13 at 09:32, Brian Duffy wrote:
> > > Maybe I'm wrong but I was going on the assumption that the vapi
> authors are
> > > not basing their version numbers on "minor" releases such as
> clutter-1.8 or
> > > clutter-gst-1.4 or whatever. For instance, when  include the clutter
> > > package in my application I am using --pkg clutter-1.0 even though I am
> > > using the clutter-1.8 that F16 has available through yum.
> >
> > that's because the "1.0" fragment of the "clutter-1.0" pkg-config name
> > (which is what Vala uses to find the library compiler and linker flags
> > when you use the --pkg command line argument) is the API version, not
> > the Clutter version.
> >
> > Clutter 1.8 still allows you to use the API of every other release of
> > the 1.x series, as it's API and ABI compatible.
> >
> > > I would be interested if anyone can clarify what the deal is here. I
> would
> > > hate to think that Vala is only providing functionality that has
> existed in
> > > clutter since 1.0 or Clutter-gst since 1.0. I can't believe that is the
> > > case.
> >
> > it's exactly the case, but it's probably not what you meant. any
> > function at the time 1.0 was released is still available in Clutter 1.8;
> > if you need a specific version of Clutter you'll have to check the
> > version using pkg-config at configure time.
>
> No it isn't. I think you missed the word "only". Vala isn't /only/
> providing functionality that has existed in Clutter since 1.0, it is
> providing all the functionality that the library (or libraries)
> referenced by that pkg-config file provide up until the last time the
> VAPI was updated.
>
> > Clutter itself has two ways for checking at compile time and run time
> > what version is being used:
>
> It's also worth noting that, AFAIK, most people just use pkg-config to
> test against a minimum required version using the PKG_CHECK_MODULES
> macro.
>
> >   • the CLUTTER_CHECK_VERSION() macro, which can be used to delimit a
> >   section in the C code, e.g.:
> >
> >     #if CLUTTER_CHECK_VERSION(1, 8, 0)
> >       clutter_object_method_added_in_1_8_0 (foo);
> >     #else
> >       clutter_object_method_available_before (foo);
> >       clutter_object_method_that_may_have_been_deprecated_later (bar);
> >     #endif
> >
> >   • the clutter_check_version() function, which can be used to check
> >   the version of the Clutter library that is *currently* running the
> >   application, e.g.:
> >
> >     if (clutter_check_version (1, 8, 0))
> >       clutter_object_method (arg);
> >     else
> >       clutter_object_another_method (another_arg);
> >
> > this obviously applies to the C API; if you need to use a method or a
> > class and the vapi file doesn't list them, then you'll have to update
> > the vapi file and either depend on a new version of Vala that ships that
> > updated vapi, or ship the updated vapi file yourself.
>
> You can also use the extern keyword to create a binding in your Vala
> code. It's a bit hackish, but not usually a problem if you're just
> missing a method or two.
>
> > yes, that's a problem of Vala, and the fact that all vapi files are
> > centralized with Vala, instead of living outside of the project.
>
> We don't have a problem with upstream libraries distributing their own
> VAPIs. In fact, I rather prefer the idea... examples of this include
> (according to share/vala/vapi in my jhbuild environment):
>
>      * atasmart
>      * champlain
>      * colord
>      * dconf
>      * folks
>      * gee
>      * gssdp
>      * gtk-vnc
>      * gupnp
>      * libcanberra
>      * libosinfo
>      * libproxy
>      * libvirt
>      * rygel
>      * spice
>      * telepathy
>      * tracker
>
> That said, many projects aren't going to want to deal with Vala because
> of the additional maintenance cost, a lack of familiarity with Vala,
> apathy, etc.
>
> If Clutter would like to build and distribute its own VAPI I certainly
> wouldn't have any objection, and I don't think anyone else would either.
> I would even be willing to help maintain the bindings.
>
> That offer goes for everyone, not just Clutter or even GNOME. If you
> would prefer to distribute a VAPI with your project I would be happy to
> help integrate the bindings into your build system and assist with
> maintenance. After all, it's not really any more work for me to maintain
> bindings upstream than in Vala.
>
> If you don't want to distribute a VAPI with your project, just recognize
> that we may forget to update our VAPI, especially for less popular
> packages. Feel free to file a bug report at [1], or even just ask on IRC
> (my nick is nemequ on gimpnet and freenode). Also, keep in mind that
> Vala follows the GNOME release schedule; a new stable branch is only
> released every six months, and distributions don't tend to package
> unstable releases.
>
>
> -Evan
>
> [1] https://bugzilla.gnome.org/browse.cgi?product=vala
>
> _______________________________________________
> vala-list mailing list
> vala-list gnome org
> http://mail.gnome.org/mailman/listinfo/vala-list



-- 
Duff