On Wed, Dec 24, 2014 at 11:47 AM, David Edmundson <da...@davidedmundson.co.uk> wrote: > > > On Wed, Dec 17, 2014 at 12:47 PM, Harald Sitter <sit...@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 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
