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