Re: [PATCH] gnu: kde: Add kdelibs.

[Andreas Enge <andreas@enge.fr>]

Thanks for your comments!

On Wed, Nov 05, 2014 at 02:18:24PM +0100, Ludovic Courtès wrote:
> Perhaps eventually you’ll find it convenient to have a specific build
> system with those listed as implicit inputs, though.

This sounds like a good idea. I considered a "define" with a list of the
basic packages that every KDE package needs as input, but inheriting a
new build system from the cmake build system sounds like a plan.

> > The configure flags
> >    "-DCMAKE_SHARED_LINKER_FLAGS=-lQtNetwork -lQtXml"
> >    "-DCMAKE_EXE_LINKER_FLAGS=-lQtCore"
> > look like bugs in kdelibs to me; but I wonder if reporting them makes sense.
> What does it fix?  Would be nice to leave a comment above it.

As usual, the libraries and binaries are not explicitly linked with the
libraries they depend on. So in a context where the input libraries are not
in /usr/lib, executing binaries fails.

In my private branch I also tried to compile a few KDE packages. The same
problem everywhere: Unless I set an LD_LIBRARY_PATH, they do not find the
necessary KDE and Qt libraries. I think we need a more general solution,
as also witnessed by this:

On Wed, Nov 05, 2014 at 09:49:39PM +0800, 宋文武 wrote:
> Hi, when packaging libqtxdg(using cmake and qt5), I find out that I have
> to set CMAKE_SHARED_LINKER_FLAGS too to get qt5 into output's rpath.
> Then I do a similar build for libqtxdg in nix for comparision, which do not
> need to set this variable.

Maybe someone here can come up with a good solution? In any case, I will
try to discuss with Ludovic and my personal cmake guru.

> > Quite a few of the tests fail, and already the first one (which is a simple
> > compression and archiver test) hangs at 100% CPU before being killed after
> > 1500s. I can try to run all the tests and see whether there is some useful
> > output. Otherwise hunting down the test failures looks hopeless.
> It would be nice to investigate a bit, but IMO it can be done
> incrementally (commit with #:tests? #f and a FIXME, and then see what
> can be done.)

Agreed; the package is not finished yet, as one of the last steps I should
at least look at the test results (unless many of the about 150 time out
after 1500s...).

> > -  #:use-module ((guix licenses) #:select (bsd-2 lgpl2.0+ lgpl2.1 lgpl2.1+ lgpl3+))
> > +  #:use-module ((guix licenses) #:select (bsd-2 lgpl2.0 lgpl2.0+ lgpl2.1 lgpl2.1+ lgpl3+))
> At this point, it’s probably better to just use #:prefix.  :-)

Okay!

> I suspect automoc4, bison, flex, and docbook-* should be in
> ‘native-inputs’.

Probably so.

> > +    (synopsis "Main libraries for the KDE desktop")
> > +    (description "KDE desktop environment")
> Make sure to improve it before committing.

Okay.

> > +    (license lgpl2.0))) ; the libraries; examples are under GPL
> It’s version 2.0 only?

A bunch of files, yes. I just realise that the truth is really messy:
   http://metadata.ftp-master.debian.org/changelogs/main/k/kdelibs/oldstable_copyright
There is also LGPL2+, "deal in the software without restriction", etc.
and so on.

Andreas