On Thu, 05 Jul 2018 at 09:20:55 -0400, Kyle Edwards wrote: > Our plan is to > change VTK's upstream CMake scripts to make it more distro-friendly, > then provide packaging scripts that take advantage of these changes. > (We've already made some of these changes in the latest VTK master - it > now automatically installs its libraries in /usr/lib/<arch> if built as > a Debian package.)
debhelper's Debian::Debhelper::BuildSystem::cmake already passes -DCMAKE_INSTALL_LIBDIR=lib/$DEB_HOST_MULTIARCH (among other options) to packages built using cmake, although for some reason it only does this when cross-compiling (this seems sufficiently odd that I've reported it as a bug). The most helpful thing that CMake could do here would be to have a predictable set of conventional installation paths, similar to the --libdir, --bindir etc. in Autotools and Meson, so that debhelper can define the same paths for all CMake-built packages and have the right things happen 99% of the time, as it already does for Autotools and Meson. If I understand correctly, CMake doesn't *necessarily* provide anything like this, but individual CMake-using projects can opt-in to it by using <https://cmake.org/cmake/help/latest/module/GNUInstallDirs.html>? (debhelper does set many of those variables, in the hope that the project being built uses GNUInstallDirs.) In general I think we prefer upstream build systems to do something predictable rather than something clever, because we're usually going to be passing options to them anyway (so that the clever thing they do doesn't change unpredictably when the build system is upgraded; debhelper's compat levels put a package maintainer in control of when they deal with potentially incompatible changes). It's best if we can pass essentially the same options to every package built with a particular build system, as we do for Autotools and Meson. smcv
