qca-qt5 package name

[Harald Sitter]

On Wed, Dec 24, 2014 at 11:47 AM, David Edmundson
<david at davidedmundson.co.uk> wrote:
>
>
> On Wed, Dec 17, 2014 at 12:47 PM, Harald Sitter <sitter at kde.org> wrote:
>>
>> alohas.
>>
>> recently the QCA maintainer and I got into a discussion [1] whether a
>> qca-qt5 library should be a different config inside the same cmake
>> package or an independent one (detailed discussion in the longest
>> comment thread of the review).
>>
>> > find_package(Qca NAMES Qca-qt5 Qca-QT5 Qca-5 Qca REQUIRES)
>>
>> or
>>
>> > find_package(Qca-qt5)
>>
>> former is very much in line with the maintainer's expectation of how
>> qca is supposed to have any odd suffix supplied by the distro [2] that
>> would eventually disappear,
>
>
> If the prefix ever disappears, aren't we going to end up with exactly the
> same crisis in reverse, with Qt4 apps now accidentally linking against a Qt5
> library with exactly the same name?

Yes, although to be perfectly honest that is a general problem with
how we use cmake (or name our libraries, respectively the cmake
package).

If I have
- libfoo.1
and then do a BIC I'd bump to
- libfoo.2
on a CMake level the package is still called foo though.

An application using foo would have done something like this to use libfoo.1:
- find_package(foo "1.0")
Problem is that this still works after a soname change to libfoo.2
even though that new version is potentially not suitable. At this
point the best one can do is hope that something in the
compilation/linkage goes wrong and the build explodes.

I think(tm) the way to fix this properly (which I have not ever seen
done by us :P) is fiddling with the find_package related variables
(supposedly PACKAGE_VERSION_COMPATIBLE would be used) to indicate that
a given candidate package is not compatible for what was looked for.
This combined with the way find_package finds its cmake config
(globbing), by the way should allows for easy installation
compatibility even in the simplest of libraries.

i.e.

- cmake/libfoo1/FooConfig.cmake
  checks PACKAGE_FIND_VERSION -> sets PACKAGE_VERSION_COMPATIBLE=false
if not something like 1.*

- cmake/libfoo2/FooConfig.cmake
  as libfoo2 but makes sure the looked for version is 2.*

- headers get installed to a soname'd dir (which we kind of have for
KF5 at large but not individual libs)

There, that went a bit off-topic but now I got that off my chest as well ^^

HS