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