guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ludovic Courtès
Subject: Re: [PATCH] gnu: kde: Add kdelibs.
Date: Thu, 06 Nov 2014 12:46:21 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)

Andreas Enge <address@hidden> skribis:

> On Wed, Nov 05, 2014 at 10:18:18PM +0100, Andreas Enge wrote:
>> It definitely sounds like a good idea. We could add the rpath linker flags
>> for Qt and for KDE via -DCMAKE_SHARED_LINKER_FLAGS and
>> -DCMAKE_EXE_LINKER_FLAGS to the kde build system. I would like to give
>> it a try.
>
> It works! I am attaching the updated kdelibs patch (still not finished,
> just for your information; but I took Ludovic's suggestions into account).

Cool!  LGTM.

> So for the kde build system, we could add such lines to code the Qt and KDE
> libraries into the rpath. Different submodules (at least kdegames)
> also come with their own additional libraries. Anyway, I had the intention
> of creating separate guile modules for them to keep a manageable number of
> packages per module. So one could imagine a KDE build system, and a local
> extended variant in each module inheriting from it.
>
> So is this a solution we should implement, or does anyone have a better idea
> or an argument why this would be bad?

Apologies if this was already mentioned, but why don’t
-DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE and
-DCMAKE_INSTALL_RPATH=$out/lib (in cmake-build-system.scm) lead to
binaries with a RUNPATH?  As Eric said, this should produce binaries
with an appropriate RUNPATH, no?  Or does it only take care of setting
the RUNPATH to $out/lib?

To me, passing -Wl,-rpath would be a workaround for a package-specific
defect.  The ideal solution would be to have cmake-build-system DTRT.

Thanks,
Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]