Return-To-The-Roots / s25client

Return To The Roots (Settlers II(R) Clone)
http://www.rttr.info
GNU General Public License v2.0
478 stars 77 forks source link

installation fails #592

Closed hasufell closed 7 years ago

hasufell commented 8 years ago

This is because the installation is not proper cmake install rules, but gets piped to some shell scripts (I don't even know why). These shell scripts make assumptions about where the build directory is and when used with distro packaging, it can lead to things like:

jule@localhost ~/git/s25client-build $ make DESTDIR="/home/jule/git/s25client/install" install
[  0%] Built target version
       version: started
                source directory: "/home/jule/git/s25client/"
                build  directory: "/home/jule/git/s25client-build/"
                build_version_defines.h is unchanged
       version: finished
[  0%] Built target updateversion
[  1%] Built target videodrv
[  1%] Built target audiodrv
[  2%] Built target videoSDL
[  7%] Built target s25util
[  9%] Built target endian
[ 11%] Built target audioSDL
[ 12%] Built target mygettext
[ 22%] Built target siedler2
[ 23%] Built target lobby_c
[ 24%] Built target resample-sndlib-20
[ 25%] Built target s-c_resample
[ 26%] Built target sound-convert
[ 27%] Built target s25update
[ 32%] Built target translations
[ 96%] Built target s25Main
[ 96%] Built target s25client
[100%] Built target Test
Install the project...
-- Install configuration: ""
-- Running preinstall script
## Installing for "Linux"
## Using Path-Prefix "/usr/local"
## Using Binary Dir "/usr/local/bin"
## Using Data Dir "/usr/local/share/s25rttr"
## Using Library Dir "/usr/local/share/s25rttr"
## Using Destination Dir "/home/jule/git/s25client/install/"
## Creating directories
mkdir: created directory '/home/jule/git/s25client/install'
mkdir: created directory '/home/jule/git/s25client/install//usr'
mkdir: created directory '/home/jule/git/s25client/install//usr/local'
mkdir: created directory '/home/jule/git/s25client/install//usr/local/bin'
mkdir: created directory '/home/jule/git/s25client/install//usr/local/share'
mkdir: created directory '/home/jule/git/s25client/install//usr/local/share/s25rttr'
mkdir: created directory '/home/jule/git/s25client/install//usr/local/share/s25rttr/S2'
mkdir: created directory '/home/jule/git/s25client/install//usr/local/share/s25rttr/RTTR'
mkdir: created directory '/home/jule/git/s25client/install//usr/local/share/s25rttr/driver'
mkdir: created directory '/home/jule/git/s25client/install//usr/local/share/s25rttr/driver/video'
mkdir: created directory '/home/jule/git/s25client/install//usr/local/share/s25rttr/driver/audio'
mkdir: created directory '/home/jule/git/s25client/install//usr/local/share/s25rttr/../doc'
mkdir: created directory '/home/jule/git/s25client/install//usr/local/share/s25rttr/../doc/s25rttr'
## Installing binaries
cp: cannot stat './../release/bin/rttr.sh': No such file or directory
CMake Error at /home/jule/git/s25client/cmake/preinstall.cmake:11 (MESSAGE):
  ERROR: Preinstallscript failed: Maybe you need administrative privileges?
Call Stack (most recent call first):
  cmake_install.cmake:36 (include)

make: *** [Makefile:127: install] Error 1

Which means the scripts assume some relative paths.

Using ./cmake.sh from the build directory is not an option, because it's required that we can interface with cmake directly. That works pretty well for the build process, but not for the installation.

Flamefire commented 8 years ago

Added this as a bug, but I think you don't use it as intended. If you want to change the target dir, use "cmake [...] -DRTTR_PREFIX_DIR=/home/jule/git/s25client/install" or set "DESTDIR" before and rerun cmake. I'm confused about all those paths however so I'm not quite sure, what is and what is not a real bug.

hasufell commented 8 years ago

If you want to change the target dir, use "cmake [...] -DRTTR_PREFIX_DIR=/home/jule/git/s25client/install" or set "DESTDIR" before and rerun cmake.

Setting DRTTR_PREFIX_DIR to the target destination will mess up pretty much all paths. Only DESTDIR must be used for that and it is set.

However, this is not a target dir problem. The problem is that the install rules are not cmake install rules, but get mangled by shell scripts that don't properly know what's happening, which is why it makes assumptions here. I was able to work around it by setting RTTR_SRCDIR, but then it fails in another place, because it tries to copy libminiupnpc.so to /usr/lib/libminiupnpc.so unrequestedly and fails to do so, since that may or may not be a valid path, depending on the system (and you can't have enough checks to know whether it is).

IMO, the installation method needs to be completely rewritten. It shouldn't rely on shell scripts that guess locations. It should use cmake install rules: https://cmake.org/cmake/help/v3.0/command/install.html and use GNUInstallDirs for linux. That's the only way to be distro friendly.

I wouldn't make this a high-priority bug though, because packagers can still use their own installation method, e.g. https://git.io/vi0wZ

Flamefire commented 8 years ago

I'd certainly like someone with a decent understanding of Linux and Windows paths rework the paths and the install system. Basically we have 3 goals: Build into the build folder or an outofsource-dir and run/debug it directly from there, same for windows (MSVC), and also install into a user defined location. I'm not sure why we need ~6 paths for that and cannot simply have a prefix path (CMAKE_INSTALL_PREFIX preferably) and all others get derived from that. I think @Flow86 explained the reasons, but can't remember. There are also work-arounds in place for CMAKE_INSTALL_PREFIX and DESTDIR which look odd.

It looks like the shell scripts (pre/postinstall) are used for deploying it from the build server. So maybe one can move all the common functionality and add a different make target for this stuff (probably cmake only) that e.g. extracts the debug information etc. But this can't be me due to a lack of deeper knowledge of this stuff (windows dev mainly)

hasufell commented 8 years ago

Another problem is that reworking the build system involves pretty much all submodules, which is a pain in the a\ to create PRs for.

Contribution would be easier if this was one repo.

Flamefire commented 7 years ago

Fixed in #605