Re: [Vala] Binding problem or ClutterGst problem or my problem?
- From: Steven Oliver <oliver steven gmail com>
- To: Emmanuele Bassi <ebassi linux intel com>
- Cc: clutter-app-devel-list clutter-project org, vala-list gnome org
- Subject: Re: [Vala] Binding problem or ClutterGst problem or my problem?
- Date: Fri, 13 Jan 2012 14:51:58 -0500
Surely when they created Vala they saw that coming. Why package VAPIs with
Vala to start with? Was it expected you'd retrieve VAPIs manually in
situations like this and keep and track yourself, leaving the provided set
as (for lack of a better word at the moment) backups?
Steven N. Oliver
On Fri, Jan 13, 2012 at 12:46 PM, Emmanuele Bassi <ebassi linux intel com>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.
Clutter itself has two ways for checking at compile time and run time
what version is being used:
• 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.
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.
ciao,
Emmanuele.
--
Emmanuele Bassi,
Intel Open Source Technology Center
_______________________________________________
vala-list mailing list
vala-list gnome org
http://mail.gnome.org/mailman/listinfo/vala-list
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]