cdrkit without cmake
solar at openwall.com
Sun May 17 13:24:52 PDT 2009
We wanted to introduce cdrkit into Openwall GNU/*/Linux (Owl), a small
distro for servers, but the build-time dependency on cmake seemed
prohibitive for us. One of the key features of our distro is ability to
rebuild itself without requiring anything external, so we'd have to
introduce cmake, yet that would be unneeded 3.5 MB of compressed
"sources" (for the original .tar.gz file) plus maybe a binary package of
a few megs. A way to reduce that wastage would be to re-package the
cmake tarball dropping files not used during cmake build on Linux and
using better compression - that brings it down to 2 MB - then only build
and use cmake during cdrkit build, dropping the cmake binaries
afterwards. Still, that wouldn't be pretty, we find 2 MB wasteful, and
this would involve significant build time overhead (on building cmake).
The workaround we ended up implementing for now is to apply some strace
and sed-fu to a cmake-enabled build of cdrkit to semi-automatically
produce a cmake-less build script for cdrkit. Thus, cmake may be
required for updates of our package to new versions of cdrkit, but it is
not required for builds (including with changed patches, etc.) This is
working well so far, although we're yet to see what the maintenance
overhead will be as we update to future versions of cdrkit.
In case any other distros are in the same boat, here's our cmake-less
This includes our README-cmakeless file with step-by-step instructions
for regenerating the build scripts.
It also includes several cdrkit patches unrelated to our cmake-less
builds (e.g., while Red Hat's cdrkit-1.1.8-werror.patch simply shuts gcc
warnings up, our cdrkit-1.1.9-owl-fixes.diff actually addresses the same
shortcomings, albeit to a limited extent - cdrkit is dirty stuff).
Needless to say, other distros and upstream are welcome to reuse any or
all of this. (OK, upstream definitely won't reuse the cmake-less build
scripts, although I'd be happy if the dependency on cmake is removed by
some other means.)
P.S. When replying, please note that I am not subscribed to
Debburn-devel. However, I am subscribed to Distributions.
More information about the Distributions