This section by Tom Lees <tom@lpsg.demon.co.uk> on Tue, 4 Mar 1997
21:34:57 +0000, with subsequent modifications by Klee Dienes
<klee@debian.org>
This chapter contains general notes about the conversion to
automake. If you plan on doing anything with dpkg,
you should probably read all of this file first. You have been warned.
Automake has several significant advantages, including:
it supports emacs lisp properly
It supports libtool properly
it includes the aclocal utility
The aclocal utility is a very useful program which will
automatically build an aclocal.m4 file from the
configure.in file to include the appropriate macros.
This doesn't affect anything other than rebuilding the Makefile.in
files from the sources.
Probably the main difference which is noticable is that instead of using
proprietary directory names, it now supports configure
--sharedstatedir, and configure --localstatedir. To set these to
the Debian defaults, you should use ./configure --localstatedir=/etc
--sharedstatedir=/var/lib.
I have also customized the canonicalizing macros found in autoconf to
include the old way of finding the dpkg ``architecture'', i.e. to
be a bit more smart. Instead of it trying to determine the architecture only,
I changed it to use the `host', `build', and `target' system types. The target
CPU type is checked against the archtable to find the architecture on which
dpkg will run.
It uses gcc --print-libgcc-file-name to find out the build
architecture if possible (used later to determine ELF or a.out
format), and also uses dpkg --print-architecture if possible to modify
the cpu field before it passes on the target alias to config.sub. If
you want to specify the architecture, you should now use "--target=",
rather than --with-arch, which was essentially a hack anyway. The old
--with-arch is still there, but it is somewhat less functional. I
have also moved the DPKG_CACHED_ macros into dpkg.m4 to make
configure.in a bit more readable.
I also converted to libtool (which can be found in the Debian distribution
now). Essentially, this means that all the dpkg tools can be compiled against
a shared libdpkg without much hassle (in fact, it is the default).
You do not need to install libtool to use this feature (it works like
autoconf), and generally, it should not be needed much at all.
The new dist targets will build a distribution including all files
built by the debiandoc2html, debiandoc2ps, etc.,
which are included in the distribution so that people may build
dpkg without these (especially useful to porters).
A target make debian has been added, which will build the Debian files
from a working directory (does a make dist first). Now all we need is
a modified dpkg-source so that the dpkg-1.4.0.8.tar.gz
GNU-distribution file can be used as part of the Debian distribution. I'm
working on this, but it doesn't work too well at the moment (find it in
examples).
I removed the make portable target - it doesn't do anything useful.
I have added make uninstall targets to aid non-Debian users who simply
want to try out certain Debian packages, and the "dist" targets are
also useful to build a "distribution" of the dpkg tool. Note that
since automake automatically includes dependencies into the Makefiles in a
distribution, if you want to modify the C files, it would be advisable to get
and install automake, and then re-run it in the base dpkg distribution
directory, so that automatic dependency generation will be switched back on,
and any dependencies which change will be taken account of. The "make
maintainer-clean" targets will remove all files which any of the following
utilities create:
automake
autoconf
aclocal
autoheader
gettextize
libtoolize
If you want to modify any of the sources, I recommend that you do the following
first (after having installed the appropriate utilities, of course):-
make maintainer-clean
aclocal
autoheader
autoconf
gettextize
libtoolize (do not let automake run this, as it will cause it not to include
the libtool files in the dist targets)
for i in COPYING INSTALL; do ln -s /usr/share/automake/$i .; done
automake
I have also incorporated the patches originally made by Galen Hazelwood to
internationalize dpkg using GNU gettext - see the file "NOTES.intl"
for more information about this.
Other minor changes are:
The version number is now determined from debian/changelog, not from the
directory name.
Creation of version.h now handled from configure script, not Makefile.
include/dpkg.h is now generated from include/dpkg.h.in by a sed script,
inserting the appropriate directory definitions - so now it supports changing
the dpkg directories (can install in /usr/local)
Updated the COPYING (1 very minor change) and INSTALL files to those
distributed with automake-1.1l
Since the shared libdpkg is now installed, I also made include/Makefile install
dpkg.h and dpkg-db.h into /usr/include by default
Questions:
Should I use localstatedir and sharedstatedir instead of
sysconfdir and datadir?
1.2 Internationalization
This section by Galen Hazelwood.
Dpkg is, to say the least, generous in its error reporting. The vast majority
of the output strings are error messages of one kind or another. And if you
feel that you've stumbled into the Department of Redundancy Department, you
would be absolutely correct. Many of the error messages in dpkg.pot are
duplicates, used at different points in the program.
To avoid swamping the translators completely, I made some executive decisions
on what kinds of strings to translate. All the strings sent to debug() are
left alone, on the grounds that these are for dpkg developers, and not for the
general public. Most interal error messages were very cryptic, and would
probably confuse the translators when seen just sitting there in the dpkg.pot
file, and are also left alone. (I did mark some of the more verbose ones for
translation.)
If others disagree with me about the necessity of translating these strings,
it's easy enough to just go through and mark them later.
I added the startup gettext code to the main routine in dselect, which was
necessary as many of the strings in lib are translated. Dselect is otherwise
unchanged.
Changes:
The files in intl and po were taken from gettext 0.10.26, by way of the
gettextize program. I altered the makefiles to remove the VERSION symbol,
which is only used in targets which dpkg does not support.
aclocal.m4 was stolen from the textutils package, configure.in was altered to
use these new tests, symbols were added to acconfig.h, and the two new
directories were added to Makefile.in.
The dpkg, dpkg-deb, md5sum, split, and dselect Makefiles now look for headers
in ../intl, and try to link with whatever i18n libraries configure finds. They
also now define LOCALEDIR in CFLAGS.
include/dpkg.h has the necessary NLS boilerplate, and the only file which
dosen't include this (md5sum/md5sum.c) had it added directly.
The most intrusive change is due to a disagreement between xgettext and the
dpkg coding style. Although xgettext understands string constant
concatenation, it can't handle the case where preprocessor symbols are used as
well. The dpkg code uses this a lot, especially in cases like this:
ohshite("error reading from " BACKEND " pipe");
where BACKEND is defined as "dpkg-deb". Because xgettext can't
handle this, I have changed this usage in all cases to something like:
ohshite(_("error reading from dpkg-deb pipe");
This isn't very kind to Ian, I know. But what can I do?