Re: [Libexif-devel] libexif API changes

[Christopher A. <ca...@re...>]

Lutz M=FCller wrote:

>>Other=20
>>applications should be reluctant to require libexif if that is the case.
>>   =20
>>
>
>In the MS-Windows world, people copy & paste the code into their
>projects. That's always an option to avoid every problem. The small size
>allows for that. In gphoto2 I have used AC_CHECK_LIB and
>AC_CHECK_HEADER. In addition, we provide pkg-config --modversion.=20
>
>If you give me the names of projects that do not use those methods for
>avoiding troubles compiling with libexif, I will look into fixing them.
> =20
>
The problem is not that you don't provide the means to check the version=20
at compile time, but the fact that you have to, really.  Thankfully the=20
soname changed....

The package I am talking about specifically is nautilus.  The patch for=20
it is easily done; in fact I have one for alexl, and I believe debian=20
merged one into their tree as well.  The issue that alexl is a bit=20
concerned with is if the interfaces will be frequently changing, causing=20
much more headache down the line.  Why shouldn't nautilus be able to be=20
compiled and run against whatever version of libexif the user has=20
installed?  Changing the interfaces makes that harder.  Not impossible. =20
But harder.

> =20
>
>>Additionally, I will note that it would probably be nice to expose=20
>>LIBEXIF_CURRENT or similar in a .h file which things can #include to=20
>>support building against multiple versions of libexif.
>>   =20
>>
>
>This is easily done in the individual project using above outlined
>methods (isn't this what configure.in files are for?).
> =20
>
Sure, it can be done in configure.in, but it is much easier to write:

#if LIBEXIF_CURRENT >=3D 10
  /* new api */
#else
  /* old api */
#endif

than to do configure checking, and more robust than having the package=20
assume knowledge about which API versions correspond to which libexif=20
releases.