More libalkimia problems/questions was: problems compiling 4.8 on system with both qt4 and qt5

[Ralf Habacker]

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