new build system
So, while we wait for the dpkg maintainers to review the dpkg-source v2
code, I decided to address another thing I think is broken about our
source format: the excessive complexity and redundancy in debian/rules.
I was strongly influenced by Christoph Lameter's u-os package manager
source format (http://www.u-os.org/upm.html). One basic idea is to make
simple things simple, and hard things possible.
I attempted to take some of these ideas, and adapt them to the Debian
build system; in particular, debian/rules. The result is currently
called Colin's Build System, but don't let the name give you the
impression that it is at all similar to Doogie's Build System or any of
the other build systems floating around there. Instead, CBS is more of
a meta-build system; it just provides sane defaults, and lets you
customize things as needed.
CBS is currently implemented using debhelper. My ultimate plan is to
integrate both CBS, along with a subset of debhelper into
build-essential somehow (probably in a package named something like
build-common). Combined with dpkg-source v2, I think the result will be
a massive reduction in packaging complexity and required maintenance for
the vast majority of packages.
But unlike dpkg-source v2, you can start using CBS right now. Sound
interesting? Here's the URL where you can download CBS:
http://cvs.verbum.org/debian/rules
For several of my packages, I have no need to customize the build rules
*at all*; the defaults Just Work. For a few more of my packages, I've
only had to add one line of customization in debian/rocks. To
understand how this works, here's the first part of the CBS docs:
### Introduction to Colin's Build System #############################
# This file is shared between all the packages which use Colin's Build
# System. The idea is that this file contains sane defaults, and
# stuff specific to a package should go into the debian/rocks Makefile
# fragment. There generic hooks where you can override and add
# functionality for a specific package.
# The big motivating factor for CBS was originally that more and more
# programs today are created using GNU configure scripts and GNU
# automake, and as such they are all very similar to configure and
# build. CBS takes advantage of this by doing stuff like looking for
# an executable file named "configure"; if it exists, CBS tries
# treating it like a GNU configure script, and passes it sane
# arguments (like --prefix=/usr). This will work for like 90% of the
# cases out there (including at least all my packages). But if it
# doesn't work, no problem; you can customize or just completely
# override it the debian/rocks file. For example, suppose that you
# need to pass "--enable-foo" to the configure script. In that case,
# all you need to do is create a file named debian/rocks, which
# contains:
# DEB_CONFIGURE_EXTRA_FLAGS := --enable-foo
# And that's it! Everything else happens automagically. However,
# suppose that your "configure" script isn't made by autoconf, and
# instead expects the user to interactively configure the program
# (e.g. Perl). In that case, you can just override the
# "deb-common-configure" rule, by putting something like the following
# in your debian/rocks:
# deb-common-configure:
# ./configure --blah --blargh < debian/answers
# All of the rules which are overridable are listed below, up to the
# line "-include debian/rocks". There are also a large group of
# variables you may customize to affect a default rule, instead of of
# just overriding the rule completely.
# CBS also helps you keep up-to-date with the latest policy; when
# there is a new DEB_BUILD_OPTIONS entry, or they change semantics (as
# in the latest "debug" => "noopt" change), you shouldn't have to
# change anything in your packages (besides rebuilding them with the
# latest CBS version); CBS will just handle it.
### CBS and Debhelper ################################################
# Colin's Build System currently relies heavily on debhelper version
# 4, so you must have a Build-Depends: debhelper (>= 4.0.0).
### Single vs. Multi Binary packages #################################
# If you have a single binary package, CBS tries to use the upstream
# Makefile to install everything into debian/packagename, so it will
# all appear in the binary package. To remove files, move them
# around, just override the deb-binary-hook-<packagename> target in
# the debian/rocks file, like:
# deb-binary-hook-mypackage:
# mv debian/mypackage/usr/sbin/myprogram debian/mypackage/usr/bin/myprogram
# rm debian/mypackage/usr/share/doc/mypackage/INSTALL
# If you have a multi-binary package, CBS (by default) uses the
# upstream Makefile to install everything in debian/tmp. After this,
# the recommended method is to use dh_install to copy these files into
# the appropriate package. To do this, just create
# "packagename.install" files; see the dh_install man page.
Reply to: