[CMake] how to debug CPack creation

[Илья Шипицин]

сб, 20 окт. 2018 г. в 18:31, Eric Noulard <eric.noulard at gmail.com>:

>
>> And the content is:
>> $ rpm -qpl softether-vpnserver-5.1.9660-1.x86_64.rpm
>> /lib
>> /lib/systemd
>> /lib/systemd/system
>> /lib/systemd/system/softether-vpnserver.service
>> /usr/libexec
>> /usr/libexec/softether
>> /usr/libexec/softether/vpnserver
>> /usr/libexec/softether/vpnserver/hamcore.se2
>> /usr/libexec/softether/vpnserver/vpnserver
>> /usr/local
>> /usr/local/bin
>> /usr/local/bin/vpnserver
>>
>> the content of the .deb is similar:
>> $ dpkg-deb -c softether-vpnserver_5.1.9660_amd64.deb
>> drwxr-xr-x root/root         0 2018-10-20 14:45 ./lib/
>> drwxr-xr-x root/root         0 2018-10-20 14:45 ./lib/systemd/
>> drwxr-xr-x root/root         0 2018-10-20 14:45 ./lib/systemd/system/
>> -rw-r--r-- root/root       700 2018-10-20 14:45
>> ./lib/systemd/system/softether-vpnserver.service
>> drwxr-xr-x root/root         0 2018-10-20 14:45 ./usr/
>> drwxr-xr-x root/root         0 2018-10-20 14:45 ./usr/libexec/
>> drwxr-xr-x root/root         0 2018-10-20 14:45 ./usr/libexec/softether/
>> drwxr-xr-x root/root         0 2018-10-20 14:45
>> ./usr/libexec/softether/vpnserver/
>> -rw-r--r-- root/root   1770716 2018-10-20 14:45
>> ./usr/libexec/softether/vpnserver/hamcore.se2
>> -rwxr-xr-x root/root   2088960 2018-10-20 14:45
>> ./usr/libexec/softether/vpnserver/vpnserver
>> drwxr-xr-x root/root         0 2018-10-20 14:45 ./usr/local/
>> drwxr-xr-x root/root         0 2018-10-20 14:45 ./usr/local/bin/
>> -rwxr-xr-x root/root        72 2018-10-20 14:45 ./usr/local/bin/vpnserver
>>
>> The main question is, what filesystem layout do you expect for those
>> files?
>>
>>
> Now I think I get it.
> IN vpnserver CMakeLists.txt you do:
>
> install_systemd_service("vpnserver"
> "${CMAKE_SOURCE_DIR}/systemd/softether-vpnserver.service"
> "${CMAKE_INSTALL_FULL_LIBEXECDIR}/softether/vpnserver/vpnserver")
>
> So at this point (during CMake config step)
> "${CMAKE_INSTALL_FULL_LIBEXECDIR}/softether/vpnserver/vpnserver"
> is /usr/local/softether/vpnserver/vpnserver
>
> In your install_systemd_service CMake macro wrapper you do:
>
> macro(install_systemd_service component file_path binary_path)
>     get_filename_component(file_name ${file_path} NAME)
>     get_filename_component(binary_directory ${binary_path} DIRECTORY)
>
>     file(READ ${file_path} FILE_CONTENT)
>     string(REPLACE "[DIRECTORY]" ${binary_directory} FILE_CONTENT
> ${FILE_CONTENT})
>     string(REPLACE "[BINARY]" ${binary_path} FILE_CONTENT ${FILE_CONTENT})
>     file(WRITE ${CMAKE_SOURCE_DIR}/tmp/systemd/${file_name}
> ${FILE_CONTENT})
> ...
>
> So you generate a systemd service file which contains /usr/local prefix
> because this is the one which
> is know during "CMake configuration step".
>
> You cannot do that this way with .deb or .rpm because you don't know the
> "actual" prefix that will be in the package
> because it is controlby CPACK_PACKAGING_INSTALL_PREFIX  "at CPack time",
> i.e. when CPack runs.
>
> It's even worse because .deb or .rpm may be relocated see e.g.:
>
> https://www.cyberciti.biz/faq/howto-install-rpm-package-into-another-directory/
>
> When you want to install script that should know where things get
> installed you have 3 options:
>
> 1) Assume the binary executable is installed in the path
>     thus call the executable as-is "vpnserver" without absolute path
>
> 2) Put a pre- or post- install script that will compute the appropriate
> path
>    **during package installation** when you are sure what the real path
> will be.
>    Have a look at CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA in
> https://cmake.org/cmake/help/latest/cpack_gen/deb.html
> or
> https://cmake.org/cmake/help/latest/cpack_gen/rpm.html#variable:CPACK_RPM_SPEC_MORE_DEFINE
>
> 3) Ensure that you generate package with
>    CMAKE_INSTALL_PREFIX == CPACK_PACKAGING_INSTALL_PREFIX
>    This is ok but will break if the installation of the package is
> relocated.
>

this is good.
is there a way to install shared libs to system location ? (in order to
avoid ld manipulation)



>
> 1) may be ok.
> 2) need a little work but is the more robust
> 3) may be enough but prevent relocatable install
>
> --
> Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20181020/1649501d/attachment.html>