Review Request 124962: Fix CMAKE_INSTALL_LIBDIR not respecting installation prefix

[Xuetian Weng]

> On 八月 28, 2015, 5:33 p.m., Martin Klapetek wrote:
> > CMakeLists.txt, line 38
> > <https://git.reviewboard.kde.org/r/124962/diff/1/?file=399442#file399442line38>
> >
> >     Shouldn't this be ${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR} then?
> >     
> >     Also, are pam modules actually supported outside of the default dir (I have no clue)?
> 
> Pinak Ahuja wrote:
>     According to this: http://www.cmake.org/cmake/help/v3.0/module/GNUInstallDirs.html the syntax I've used is correct.
>     I don't know if the pam modules are supported outside the default dir either. My kdesrc build was failing because kwallet-pam was not respecting the install prefix and installing the libs in /lib64 therefore I investigated the problem.
> 
> Martin Klapetek wrote:
>     > According to this: http://www.cmake.org/cmake/help/v3.0/module/GNUInstallDirs.html the syntax I've used is correct
>     
>     Fwiw, that link only says that "${CMAKE_INSTALL_LIBDIR}" is a relative "lib/" path. The proper explanation is here: http://www.cmake.org/cmake/help/v3.0/command/install.html
>     "If a relative path is given it is interpreted relative to the value of the CMAKE_INSTALL_PREFIX variable".
>     
>     So that's good. But in other usages outside of install(), keep in mind that it gives you relative path only.
>     
>     > My kdesrc build was failing because kwallet-pam was not respecting the install prefix and installing the libs in /lib64
>     
>     Well yes, because that's where PAM expects this module to be by default. So that's a whole wrong reason for this fix :P
>     
>     But I've done the homework and it is actually possible to configure PAM with an absolute path in /etc/pam.d/stuff. So I guess this patch is fine, but I'd like to get some OKs from some distro people too.
> 
> Pinak Ahuja wrote:
>     cmake is often strange to work with. Anyways point taken :)

FYI, CMAKE_INSTALL_LIBDIR can be either a relative or an absolute path (it's a relative path by default in GNUInstallDirs), while CMAKE_INSTALL_FULL_LIBDIR always gives you an absolute path (value is obtained from CMAKE_INSTALL_LIBDIR).

When using install using CMAKE_INSTALL_XX is fine since CMAKE_INSTALL_PREFIX will be appended if it is a relative path.

IMHO, it would be better to have an option to specify the pam library directory, and having a sane default value when user didn't set it.

On some system, /lib is a symlink to /usr/lib (which is encouraged by systemd), install to /lib would be a little bit problematic for packager to package it (At packaging time symlink is usually not available).


- Xuetian


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124962/#review84546
-----------------------------------------------------------


On 八月 28, 2015, 7:39 a.m., Pinak Ahuja wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124962/
> -----------------------------------------------------------
> 
> (Updated 八月 28, 2015, 7:39 a.m.)
> 
> 
> Review request for Plasma and Martin Klapetek.
> 
> 
> Repository: kwallet-pam
> 
> 
> Description
> -------
> 
> pam_kwallet5.so was being installed to /lib(64) irrespective of what the installation prefix was set to. This patch fixes it.
> 
> 
> Diffs
> -----
> 
>   CMakeLists.txt f60ac41 
> 
> Diff: https://git.reviewboard.kde.org/r/124962/diff/
> 
> 
> Testing
> -------
> 
> pam_kwallet5.so seems to install under the directory set as CMAKE_INSTALL_PREFIX
> 
> 
> Thanks,
> 
> Pinak Ahuja
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20150830/d9cba7d9/attachment-0001.html>