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 <e...@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
_______________________________________________ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
