changeset: 126:cdcacfc6b638
tag: tip
user: f.e.negroni_AT_gmail.com
date: Tue Aug 19 00:04:52 2008 +0100
files: dwm/customisation/patch_queue.md
description:
More MQ pacth tutorial material.
Next: updating to the latest source tree
diff -r 615321a1e60f -r cdcacfc6b638 dwm/customisation/patch_queue.md
--- a/dwm/customisation/patch_queue.md Mon Aug 18 23:12:18 2008 +0100
+++ b/dwm/customisation/patch_queue.md Tue Aug 19 00:04:52 2008 +0100
_AT_@ -28,7 +28,9 @@
###Get the original dwm
You have two options:
-- download the prepackaged source tarball (currently [dwm-5.1](
http://code.suckless.org/dl/dwm/dwm-5.1.tar.gz)
+
+- download the prepackaged source tarball, currently [dwm-5.1](
http://code.suckless.org/dl/dwm/dwm-5.1.tar.gz)
+
- clone the mercurial repository at `
http://code.suckless.org/hg/dwm`
###Enable the MQ extension
_AT_@ -65,4 +67,131 @@
###Our first patch: change install location
+When trying out new software, or patching projects, I like to install it in my home directory.
+
+So the first change I make when downloading dwm is to edit `config.mk` and change the value of `PREFIX`.
+
+This is a perfect candidate for an MQ patch: it is a repetitive task, but the resulting config.mk might not be compatible with future releases.
+
+So we first tell MQ we are working on a new patch:
+
+ $ hg qnew install_location
+
+Then we edit `config.mk` and change the value of `PREFIX`:
+
+ PREFIX = /home/fnegroni
+
+We then tell MQ that we have done some work on the current patch:
+
+ $ hg qrefresh
+
+Our base repository now includes information about our patch:
+
+ $ hg log -r tip
+ changeset: 1338:8226aced4656
+ tag: tip
+ tag: qbase
+ tag: install_location
+ tag: qtip
+ parent: 1315:ce355cea9bb8
+ user: f.e.negroni
+ date: Mon Aug 18 23:24:27 2008 +0100
+ summary: [mq]: install_location
+
+###Commit the patch to the MQ repository
+
+Since we are happy about our first customisation, we want to commit that in our MQ repository. This way, should we corrupt anything in our working copy, we can always roll back to a know state.
+
+The MQ repository is one level down from the base repo:
+
+ $ cd .hg/patches
+ $ hg ci -m 'First patch to installation target'
+ $ cd ../..
+
+###The second patch: forget about config.h
+
+What we really want to modify when customising dwm is `config.def.h`.
+
+`config.h` is really just a redundant dependency if using MQ to manage customisations.
+
+Unfortunately MQ can't track renames for us, so rather than renaming `config.def.h` into `config.h`, we modify the dependency tree in `Makefile`.
+
+ $ hg qnew configh_dep
+
+Now MQ knows we are working on a new patch.
+
+We modify `Makefile` so that where it reads:
+
+ config.h:
+
+it now reads:
+
+ config.h: config.def.h
+
+This will cause a new `config.h` to be produced whenever `config.def.h` is updated, either by us as a patch, or by the official repository history.
+
+Don't forget to tell MQ we are done with the patch:
+
+ $ hg qrefresh
+
+Now we can test our patch: without copying `config.def.h` into `config.h`, `make` should succeed:
+
+ $ make
+ ...
+ creating config.h from config.def.h
+ ...
+
+Let's again commit this latest patch in our MQ repository for safe keeping:
+
+ $ cd .hg/patches
+ $ hg ci -m 'Made config.h depend on config.def.h'
+ $ cd ../..
+
+###Our first proper customisation: change the tiling factor
+
+As a first customisation, that is something we can actually see, we will modify the original factor used when tiling windows.
+
+The original value is in `config.def.h`, and it is called `mfact`.
+
+We want to change it from `0.55` to `0.5`.
+
+First, tell MQ about it:
+
+ $ hg qnew mfact_05
+
+Then edit `config.def.h` so it reads:
+
+ static float mfact = 0.5;
+
+in place of the old value.
+
+Tell MQ we are done with the patch and commit it to its repo:
+
+ $ hg qrefresh
+ $ cd .hg/patches
+ $ hg ci -m 'Our mfact is now 0.5'
+ $ cd ../..
+
+### List our patches
+
+Just issue:
+
+ $ hg qseries
+ install_location
+ configh_dep
+ mfact_05
+
+to see all the patches we created, and
+
+ $ hg qapplied
+ install_location
+ configh_dep
+ mfact_05
+
+to see which pacthes are currently applied to our tree.
+
+The order in which `qapplied` lists our patches is the order in which the patches were applied to our source tree, from top first to bottom last.
+
+###Update to the latest dwm source
+
To be continued...
Received on Tue Aug 19 2008 - 19:01:53 CEST