Am 05.11.2016 um 12:42 schrieb Christian David: > Hi Ralf, > > I still do not like this. The reason is that this just fixes the symptom, not > the problem. With these changes we make a huge technical dept. Exept for > version 4.8 we solved nearly all problems mentioned here already. Except coinstallation of Qt4 and Qt5 based alkimia binary packages. > So all changes are only a workaround to enable coinstallablity with a 5 years > old > release (which got perfectly replaced by alkimia 5). You suggest to skip 4.3.2 and use alkimia 5 or later ? My approach is to introduce an alikima version 7 covering Qt4 and Qt5 coinstallation > Also adding the version of Qt – a third party library – to the library This is a common use case used by many other libraries which depends on different version/variants of the same 3rd party library. See for example
/usr/lib64/libkdeinit4_kded4.so -> Qt4 based /usr/lib64/libkdeinit5_kded5.so -> Qt5 based /usr/lib64/libgwengui-qt4.so (gwengui api based on Qt4) /usr/lib64/libgwengui-qt5.so (same gwengui api based on Qt5) /usr/lib64/libgwengui-gtk2.so (same gwengui api based on gtk) > sounds really strange to me. I am sure this will cause more issues in > future. You see a better way to provide coinstallation of a shared library located in different unrelated binary packages having the same (base) name and forced to be installed in the same directory /usr/lib[64] ? > Regarding packaging; if there is really a fine grained configuration needed, > there are a lot of cmake variables like > > CMAKE_SHARED_LIBRARY_SUFFIX [1] > LIBRARY_OUTPUT_PATH [2] > INCLUDEDIR [3] > > and probably even more ECM variables to achive this. With them not a single > line of alkimia has to be changed. The packager can tune everything just the > way he wants to. This way, someone who just wants to compile alkimia does not > need to learn our naming conventions. You refereing to use for example CMAKE_SHARED_LIBRARY_SUFFIX on configuring alkimia to use a dedicated library name and INCLUDEDIR to setup a custom include dir to install alkimia header files on running make install ? That would unfortunally propably not solve the issues with naming and content of cmake and pkgconfig related files. I guess to support that additional variables would be required. I will take a look how this could be considered. > I really want to get away from the idea to encode any kind of version in the > library name. You recognized that the version is already added to shared libraries of alkimia binary packages ? Take a look at the installation layout of alkimia 4.3.2 -- Installing: /usr/lib64/libalkimia.so.4.3.2 -- Installing: /usr/lib64/libalkimia.so.4 -- Installing: /usr/lib64/libalkimia.so -- Installing: /usr/include/alkimia/alkvalue.h -- Installing: /usr/include/alkimia/alkquoteitem.h -- Installing: /usr/include/alkimia/alkcompany.h -- Installing: /usr/include/alkimia/alk_export.h -- Installing: /usr/share/kde4/apps/cmake/modules/FindLibAlkimia.cmake -- Installing: /usr/lib64/pkgconfig/libalkimia.pc and the same for alkimia 5.0.0 [1] -- Installing: /usr/lib64/libalkimia.so.5.0.0 -- Installing: /usr/lib64/libalkimia.so.5 -- Installing: /usr/lib64/libalkimia.so -- Installing: /usr/lib64/cmake/LibAlkimia/LibAlkimiaTargets.cmake -- Installing: /usr/lib64/cmake/LibAlkimia/LibAlkimiaTargets-relwithdebinfo.cmake -- Installing: /usr/include/alkimia/alkvalue.h [11] -- Installing: /usr/include/alkimia/alkquoteitem.h -- Installing: /usr/include/alkimia/alkcompany.h -- Installing: /usr/include/alkimia/alk_export.h -- Installing: /usr/lib64/cmake/LibAlkimia/LibAlkimiaConfig.cmake -- Installing: /usr/lib64/cmake/LibAlkimia/LibAlkimiaConfigVersion.cmake -- Installing: /usr/lib64/pkgconfig/libalkimia.pc Both shared librarie names contains version informations. How could you get rid of this, which is a basic concept on linux systems or did I misunderstood you ? A coinstallation of a Qt5 based alkimia 5.0 would need to have something like the following install layout [2] -- Installing: /usr/lib64/libalkimia5.so.5.0.0 -- Installing: /usr/lib64/libalkimia5.so.5 -- Installing: /usr/lib64/libalkimia5.so -- Installing: /usr/lib64/cmake/LibAlkimia5/LibAlkimia5Targets.cmake -- Installing: /usr/lib64/cmake/LibAlkimia5/LibAlkimia5Targets-relwithdebinfo.cmake -- Installing: /usr/include/alkimia5/alkimia/alkvalue.h [22] -- Installing: /usr/include/alkimia5/alkimia/alkquoteitem.h -- Installing: /usr/include/alkimia5/alkimia/alkcompany.h -- Installing: /usr/include/alkimia5/alkimia/alk_export.h -- Installing: /usr/lib64/cmake/LibAlkimia5/LibAlkimia5Config.cmake -- Installing: /usr/lib64/cmake/LibAlkimia5/LibAlkimia5ConfigVersion.cmake -- Installing: /usr/lib64/pkgconfig/libalkimia5.pc BTW: [11] shows an earlier mentioned issue. At that location a different installation dir need be used because /usr/include is in the compiler include path and in client code there is normally used #include <alkimia/alkvalue.h> which let compiling the Q5 variant use the include file at [11] which is wrong if /usr/include is earlier in the include order. Instead the include located at [22] should be used. If you let the user specify those details how will you be sure to avoid such issues ? Please remember that the mentioned installl layout is already implement mostly in alkimia. There are only a few adjustments in the cmake and pkgconfig files required to support all this installation stufff. Cheers Ralf
