How is KF5 packaged on major systems?

[Shaheed Haque]

Hi David,

On 23 April 2016 at 09:56, David Faure <faure at kde.org> wrote:

> Shaheed !!!
> Long time no see ;)
>

Indeed, I think it is about 10 years since I last did anything here!


> On Wednesday 20 April 2016 19:48:30 Shaheed Haque wrote:
> > The whole point of what I am doing is to automate as much as possible
> > of steps 1-4, and this question centres on step 4. How can I automate
> > identifying the correct KF5 library .so file? For example, on my
> > Ubuntu Wily system, I can start with the header files in
> > "/usr/include/KF5/KItemModels/*.h" and then I need to link against
> > "libKF5ItemModels.so".
>
> Well, we tried to keep things rather consistent, so maybe just a few rules
> are necessary.
>
> Just keep in mind that a single framework can install multiple libs (e.g.
> kio installs 5 of them).
>

Ack.


> (and that there are two kinds of forwarding headers (namespaced and
> non-namespaced),
> but if you only parse the real lowercase headers and not the forwarding
> headers then
> this doesn't matter)
>

Ack this too. The way I deal with this is as follows. I parse *all* real
and forwarding headers (except the KDELIBS4 support) to generate the
"individual" SIP files. I detect the forwarding headers by looking for
headers that have no "real" content and exactly one direct #include. So, at
this phase, there is a pretty good 1:1 mapping between the .h organisation
and the .SIP organisation.

Then, for each set of "individual" .SIP files in a directory (lowercase or
forwarding), I generate a "module SIP". This %Includes the "individual" SIP
files into a %Module, which translates the directory-based namespace on the
.h side into a Python package (and mirrors what PyQt does). All that is
automatic, driven purely off the directory hierarchy.

I then have a hand-selected list of only the new-style SIP files to
generate actual bindings for. The reduces the circa 2000 "individual" SIP
files to circa 120 .so files which are the new, namespaced, bindings. These
are to be used in the form "from PyKF5 import KDBusAddons". That seems a
natural and idiomatic model.

But with that in mind, it should be straightforward.
> E.g. include/KF5/KIOWidgets/* maps to libKF5KIOWidgets.so
>

OK. The question is really whether this naming is portable or not, across
distros and platforms. The factors weighing in my mind are:

1. I don't want to hardcode the names of paths and technology choices (.so
versus .dll) into the rules database; if it is in a file, it has to be done
in a platform independent manner. (Or worse, I need a file per platform).

2. The tooling needs to support projects other than KF5, but I want KF5 to
be easy to do as a starting point :-).

I think the net result is that the set of
files/globs/regexps/rules/whatever has to be specified on the command line,
and thus has to be compact. Taking this into account for the ~120 .so files
involved in KF5 (which is likely the worst case), I am presently
considering two options:

- Either ask the user to specify the file prefixes using a set of globs
(e.g. ""/usr/local/lib/libKF5*,/usr/lib/libKF5*" for KF5,
"/usr/liblibgrantelee*" for something else). I'm hoping that CMake could
help, but in the worst case, it is trivial to specify this amount of data
by hand on a platform basis if needed.

- Or hand code for the 120 cases, the set of files needed. This is a pain,
but it could be done using just the base name (i.e. without the lib prefix
and so suffix) as most tool chains seem to be able to handle converting
"foo" into "libfoo.so" or "foo.dll", but it is not clear how that could
work if some other platform decided to call the libraries
"/usr/lib/KF5/libkdbusaddons.so".

Now, from some experiments, it seems that - as you would expect - the globs
approach introduces no overhead in the generated output (though the linking
might take a bit longer), so for now, that is the approach I am
contemplating.

I hope that all sounds plausible. Have I missed anything?

Thanks, Shaheed


> --
> David Faure, faure at kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-buildsystem/attachments/20160423/9db0aab1/attachment.html>