On Wed, Sep 14, 2011 at 04:33:13PM -0400, Joey Hess wrote: > 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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org