WPrefs: Remove pointless 'this is annoying' warning
[wmaker-crm.git] / debian / README.build
blobbe5b8f2332563bb6df15850c951d913ddaf2b266
1 Building Window Maker for Debian
2 --------------------------------
4 * The patches
6   debian/rules scans debian/patches/ for files named *.diff and these
7   are sorted _alphabetically_ before being applied.
9   You can apply these patches by calling
11         $ debian/rules patch-wmaker-stamp
13   and remove them with
15         $ debian/rules unpatch-wmaker
17   Why are some patches in debian/patches and others are stored in the
18   debian .diff?
19   
20           For starters I (still) dislike the idea of doing:
22                 $ dpkg -x package.dsc
24           and being left with something that is not the source from
25           which the package is built.  It makes NMUs harder for both the
26           NMUer and the maintainer, mostly because people tend to get it
27           wrong (since it's undocumented).  I use CVS for (almost all
28           of) my packages, and I like to be able to take a look at the
29           source used to build certain release of a package _without_
30           having to check out that release.  On the other hand, I try to
31           send patches upstream, and over the years I've learned that
32           Debian's source package format is really not the best thing to
33           use in this context.  Merging between debian's source and
34           upstream's (after accepting patches) is messy.
36           The system used by this package is a compromise between these
37           two things: "most" of the patches are applied directly by just
38           unpacking the Debian sources, and some are left out.  The
39           things that are left out (those stored in debian/patches) are
40           in general things that should go upstream.  Things that aren't
41           really Debian specific.  Security fixes, patches submitted
42           upstream by other people, that kind of thing.  This keeps the
43           patches nicely separated, makes it easy to send the upstream,
44           to take them out and to update them if that becomes necessary.
45           In general, if it's Debian specific, patch the sources
46           directly.  If it should go upstream, put it in debian/patches.
48   The easiest way to generate patches is to use CVS.  Patches coming out
49   of 'cvs diff -u whaterver/you.modded' will just work if you put them
50   in debian/patches.  If you can't use CVS for whatever reason, just:
52   $ diff -u wmaker.orig wmaker > your.patch
54   will do the right thing.
56 * Building options
58   The following make variables are used to pass options to the configure
59   script:
61         XLOCALE  := --disable-locale
62         MODELOCK := --enable-modelock
64         XINERAMA := --enable-xinerama
66         (*) These are not used by default
68   Since these are make variables, you can do something like:
70         $ SOUND=--disable-sound debian/rules build
72   If you want to build a debugging version, this will do it:
74   $ export DEB_BUILD_OPTIONS=nostrip,debug,noopt
75   $ fakeroot debian/rules binary
77 -- 
78 vim: tw=72 ft=text