Re: A message from CMake upstream: announcing dh-cmake
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
Reply to: