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

Reply via email to