I just checked in a mod to libtoolize the dmapi user library. When this makes
its way to the outside tree I'd appreciate feedback on my changes. Anyone who
is building the library will notice libtool in the mix, and people who build
rpm and dpkg packages will notice it.
We needed to libtoolize this so we can reliably get shared libs for use by
HSMs. Given that libdm relies on some functionality provided by libhandle, I
also intend to libtoolize some or all of the xfsprogs directory (where
libhandle lives). So while you could care less about the dmapi library, I'd
appreciate it if you looked at it before I screw up the xfsprogs package :)
It seems that I cannot tell libtool about the difference between an install
goal and an install-dev goal. The common way to build packages, say rpm (in
the cases I was studying), is to have a static list of files in the rpm spec
file. We don't use static file lists in the XFS user libraries and
tools--instead, our install-sh builds a manifest for us and we suck that into
our spec file.
Ideally we'd like the dmapi-devel-<version> package to contain the following
from libtool:
libdm.a
libdm.so
libdm.la
And we'd like the dmapi-<version> package to contain the following from
libtool:
libdm.so.0.0.0
libdm.so.0
We'd really like to not have a static file list in the rpm spec file--getting
the file list from the install manifest is really nice. So I've added a
filter as part of the install and install-dev make goals to trim the manifest
depending on which type of goal we're running. The RPM dmapi and dmapi-devel
packages now build and install to my satisfaction.
I have not updated the debian packaging. For dpkg we do not use the
installation manifest--instead, it slurps up the contents of the installation
directory. Maybe the LT_INSTALL_FILTER and LT_DEV_INSTALL_FILTER that I've
added to include/builddefs.in should unlink the files they are removing from
the manifest. Is there anyone out there who can try this out?
Dean
|