Closed hasufell closed 7 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.
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
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)
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.
Fixed in #605
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:
Which means the scripts assume some relative paths.
Using
./cmake.sh
from thebuild
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.