Bug#641051: dh_auto_configure does not pass multiarch paths to cmake
Yann Dirson
Version: 8.9.6
Severity: normal
With debian/compat==9 I expected dh_auto_configure to pass some
defines to cmake for multiarch (the manpage does not seem to mention
any exception to this rule), but:
$ dh_auto_configure -v
mkdir -p obj-x86_64-linux-gnu
cd obj-x86_64-linux-gnu
cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON
-- Found Qt4: /usr/bin/qmake (found suitable version "4.7.3", required is "4.7.0")
Using LIBXML2_INCLUDE_DIR = /usr/include/libxml2
Using LIBXML2_LIBRARIES = /usr/lib/libxml2.so
-- Found Qt4: /usr/bin/qmake (found version "4.7.3")
-- Configuring done
-- Generating done
-- Build files have been written to: /work/yann/deb/tulip/tulip-git/obj-x86_64-linux-gnu
cd /work/yann/deb/tulip/tulip-git
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'oldstable'), (500, 'unstable'), (500, 'stable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.0.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages debhelper depends on:
ii binutils 2.21.52.20110606-2 The GNU assembler, linker and bina
ii dpkg-dev 1.16.0.3 Debian package development tools
ii file 5.04-5+b1 Determines file type using "magic"
ii html2text 1.3.2a-15 advanced HTML to text converter
ii man-db 2.6.0.2-2 on-line manual pager
ii perl 5.12.4-4 Larry Wall's Practical Extraction
ii perl-base 5.12.4-4 minimal Perl system
ii po-debconf 1.0.16+nmu1 tool for managing templates file t
debhelper recommends no packages.
Versions of packages debhelper suggests:
ii dh-make 0.59 tool that converts source archives
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Joey Hess
> With debian/compat==9 I expected dh_auto_configure to pass some
> defines to cmake for multiarch (the manpage does not seem to mention
> any exception to this rule), but:
to make it do anything with multiatch directories and cmake.
According to Steve in #617761, "I can't find a standard equivalent to
autoconf's --libdir for any of the other build systems supported by dh."
--
see shy jo
Yann Dirson
Right, looks like the standard cmake rules install libs into
${CMAKE_INSTALL_PREFIX}/lib/ without it being possible to override.
Looks like the shortest path to multiarch here would be to move the
lib/ and usr/lib/ contents to the appropriate dir. Maybe just
immediate children matching '\.so\>' ? That sounds a bit dwim and
fragile, though - what do you think ? debhelper probably already has
a way to tell which files are shared libs, which would be a much
better guess ?
Since compat v9 "is still open for development", it would be possible
for such a feature to jump in the boat ?
Joey Hess
> Right, looks like the standard cmake rules install libs into
> ${CMAKE_INSTALL_PREFIX}/lib/ without it being possible to override.
>
> Looks like the shortest path to multiarch here would be to move the
> lib/ and usr/lib/ contents to the appropriate dir. Maybe just
> immediate children matching '\.so\>' ? That sounds a bit dwim and
> fragile, though - what do you think ? debhelper probably already has
> a way to tell which files are shared libs, which would be a much
> better guess ?
>
> Since compat v9 "is still open for development", it would be possible
> for such a feature to jump in the boat ?
Such a scheme would generalize from moving libs after cmake install to
moving libs after an arbitrary build system install. It doesn't belong
in the cmake support code then.
The full, non-DWIM generalization is to have a syntax for controlling
what files dh_install puts where. So I'd be inclined to merge this bug
with #614731.
--
see shy jo
Yann Dirson
> Yann Dirson wrote:
> > Right, looks like the standard cmake rules install libs into
> > ${CMAKE_INSTALL_PREFIX}/lib/ without it being possible to override.
> >
> > Looks like the shortest path to multiarch here would be to move the
> > lib/ and usr/lib/ contents to the appropriate dir. Maybe just
> > immediate children matching '\.so\>' ? That sounds a bit dwim and
> > fragile, though - what do you think ? debhelper probably already has
> > a way to tell which files are shared libs, which would be a much
> > better guess ?
> >
> > Since compat v9 "is still open for development", it would be possible
> > for such a feature to jump in the boat ?
>
> Such a scheme would generalize from moving libs after cmake install to
> moving libs after an arbitrary build system install. It doesn't belong
> in the cmake support code then.
Right - and that should not badly interact with --libdir support.
> The full, non-DWIM generalization is to have a syntax for controlling
> what files dh_install puts where.
This may be useful, but my feeling is that some predefined settings
that Work for Most (tm) should be easily selectable, and possibly the
default as long as it's possible to tune it. It would be awkward to
stay with the current situation of only autotools packages doing
multiarch by default (which, depending on upstream Makefile.*
correctness, is not guaranted to work for all packages either). And
it would be awkward as well IMHO to require all lib packages to specify
the same regexps.
On the issue of specifying destinations to dh_install, I have already
noticed that the config-file version was less powerful than the
commandline. If the package.install lines were redefined to contain a
pattern and an optional destination (here again, subject to
compat>=9), a first gap would be filled.
Then a special token could be used for multiarch, like:
| usr/lib/lib*.so usr/${LIB}/
But then, that still requires manual handling for all *binary*
packages, so some default --automultiarch flag to dh_install (one that
would move shared libes as in my previous suggestion) could be easier
on the maints, while possibly not even requiring a compat bump.