On 2016.10.31 18:23, Ralf Habacker wrote:
Am 31.10.2016 um 19:45 schrieb Christian David:
> Thanks for this perfect overview! I notice that Alkimia 5 should
install its
> cmake files into .../cmake/LibAlkimia-5.0/..., everything else
looks okay. The
> cmake files should be in seperate directories because cmake expects
it that
> way.
yes
> However, we could rename the include directory into alkimia-6.0
(and -5.0).
> Then installing multiple versions is not an issue anymore. It is
set by cmake
> anyway. Maybe it should be
prefix/include/alkimia-6.0/alkimia/alkvalue.h
there are already some package doing so like gstreamer e.g
gstreamer-1.0
and gstreamer-2.0
> Then
> the includes could be #include <alkimia/alkvalue.h>
yes
> and if needed someone could create a symlink prefix/include/alkimia
-> prefix/include/alkimia-6.0.
This is not required if the include path is set in the
LibAlkimiaConfig.cmake is set to
${PACKAGE_PREFIX_DIR}/include/alkimia-6.0
> I will check how the frameworks are doing this.
>
> The /usr/local/lib64/libalkimia.so link should not be an issue. The
> distributions usually do not install it (except in -devel packages).
unfortunally this will result into a package system file conflict at
least with zypper on opensuse because it points to different targets.
> Also the find_package() call ensures that the right libalkimia.so.*
is selected (if a
> version is set). All other *.so* shared objects have unique names.
confirmed
> About pkgconfig: Since pkgconfig has no support for multiple
versions we could
> rename these files to /usr/local/lib64/pkgconfig/libalkimia-6.0.pc
I did found pkgconfig file on my opensuse system having similar
version
postfixes..
> (and change the line "Libs: -lalkimia" to contain the so-version).
not sure how to add a versioned library name here as the linker has
some
internal logic to get real library name from the -l flag.
> Or is there another style for pkgconfig?
I did not found any related spec at
https://people.freedesktop.org/~dbn/pkg-config-guide.html#writing
mentions. Samples only shows the usage of a number postfix like
-lpng12
or -lpng16
> Also I doubt that anybody is using it — it was used by the former
FindAlkimia.cmake script, though. So we are probably save to drop
> it, all projects which use alkimia (KMyMoney, Kraft and Scrooge?!)
should be cmake based.
There is one left over issue which depends on how packages are
created.
At least on opensuse creating a package named libAlkimia version 5.0
(e.g LibAlkimia-devel-5.0.rpm) and version 6.0 (named
LibAlkimia-devel-6.0.rpm) are not coinstallable. Either the package
with
version 5 or version 6 need to be have another name like LibAlkimia5
or
LibAlkimia6.
An alternative would be to use the major version of the Qt version
alkimia depends on as postfix e.g. LibAlkimia-5.0 (Qt4) and
LibAlkimia5-6.0 (Qt5) Saying things it may be useful/required to use
that postfix also on other places discussed above.
Cheers
Ralf
For Gentoo, if two versions are coinstallable, they get assigned to
different "slots" and in this case, I think the slot number would
easily correspond to the qt version (4 or 5) to align with other qt and
kde packages. Also, as Gentoo is a source based distro, they really
cannot install any files with the same name, so the base libalkimia.so
should go to libalkimia4.so and libalkimia5.so. (One of them could
stay libalkimia.so, but why not make things consistent if were changing
that much anyway?)
Jack
