tshred-configh.txt - monochromatic - monochromatic blog: http://blog.z3bra.org
(HTM) git clone git://z3bra.org/monochromatic
(DIR) Log
(DIR) Files
(DIR) Refs
---
tshred-configh.txt (5438B)
---
1 # shred config.h
2
3 27 August, 2014
4
5 As an accomplished Linux user, you have, at some point, had to deal with
6 softwares that are configured at compilation time.
7
8 If you never ran into those kind of programs, don't worry, you will one day.
9 The problem is that configuring this kind of software can be really frustrating,
10 so I'll show you a way to make these a bit more bearable.
11
12
13 ## Some background
14
15 Since the beginning, many programs running on Linux have been written in C. C is
16 a low-level programming language, which means that the machine can *almost*
17 understand it. For the machine to run the program, you have to translate the
18 source code into an executable binary file: This is called "**Compilation**".
19
20 The compilation is irreversible, so you can't modify a program once it's
21 compiled. It means that if you want to change the configuration of a software,
22 you have two possibilities:
23
24 * Modify the cofiguration file
25 * Modify the source code
26
27 Most of the time, softwares include an external configuration (like
28 `~/.bashrc`) to enable on-the-fly configuration. change config file, restart
29 software, and you're done.
30 But in some special cases, such a file can't be used for configuration. the
31 reason behind that is: speed, simplicity, stability and reliability.
32
33
34 ## How does it work ?
35
36 In order to make things easier for the user, the developpers (usually) create a
37 file named `config.h` where the configuration happens. You don't need
38 programming knowledge to edit it.
39
40 I like those programs, even though it can be a pain to handle sometimes. The
41 typical approach with these is the following:
42
43 ─── cd ~/src/c/program
44 ─── cp config.def.h config.h
45 ─── vim config.h
46 ─── make
47 CC program.c
48 LD program
49 ─── ./program
50
51 And you repeat these tasks until you get the behavior you want.
52 It does not seem hard to do. But on the long term, it can be painful... Also, if
53 you maintain some packages, it's even harder, because you always have to switch
54 between your own file, and the default one. Because you use your version, but
55 you package the software with the default values. So you keep doing this all the
56 time (on Archlinux for example) :
57
58 ─── cp src/<pkgname>/config.def.h z3bra.h
59 ─── vim z3bra.h
60 ─── cp z3bra.h config.h
61 ─── makepkg -si
62 ─── vim PKGBUILD
63 ─── cp src/<pkgname>/config.def.h config.h
64 ─── makepkg -S
65
66 This. Over and over. You replace your config with the default one, send the
67 package, recompile the package for you... *sigh* It's **really** boring !
68
69
70
71 ## Deal with it
72
73 First of all, I had to find an easy way to recompile and reinstall the software
74 on my computer. I use source-based distributions on my computers (Archlinux,
75 Crux, Alpine Linux), so it was not really hard. All I had to do was to create a
76 port for the said software, and include my own files in the building process.
77 For example, here is the typical `PKGBUILD` I use:
78
79 pkgname=<name>
80 pkgver=<version>
81 pkgrel=1
82 pkgdesc=<description>
83 arch=('i686' 'x86_64')
84 url=<url>
85 license=('GPL')
86 depends=
87 conflicts=
88 makedepends=('git')
89 source=("$pkgname::git+<gitsource>" 'config.h')
90 md5sums=('SKIP' 'SKIP')
91
92 build() {
93 cp config.h $pkgname/config.h
94 cd $pkgname
95 make
96 }
97 package() {
98 cd $pkgname
99 make DESTDIR=$pkgdir install
100 }
101
102 Now my file will be copied over before compilation, so all I have to do now is
103 `makepkg -fi`, and the sources will be updated, compiled and installed.
104
105 The compilation/installation part being set up
106
107 The first problem I had is that you need to keep the sources on your
108 computer, or at least the `config.h` of all the software you use. For this, I
109 created a special directory in my `$HOME` to hold all the different versions of
110 those files:
111
112 ─── tree ~/.hm.d
113 /home/z3bra/.hm.d/
114 ├── 2bwm
115 │ ├── config.def.h
116 │ └── z3bra.h
117 └── tmenu
118 ├── bright.h
119 ├── config.def.h
120 └── dark.h
121
122 2 directories, 5 files
123
124 Each directory is related to a software, and each file a specific configuration.
125 Now, I can keep track of all my config files, and they are all in the same
126 place.
127
128 PROTIP: you can even version your ~/.hm.d directory, to keep track of the
129 changes you make !
130
131 I then wrote a small script: [hm](http://git.z3bra.org/scripts/files/hm.html)
132 (for "Header Manager") to automate the process of saving/restoring
133 configurations.
134
135 It will browse the `~/.hm.d` directory for specific config files, or the default
136 ones and replace them in the current folder, automating the config replacement.
137 Now my workflow is the following:
138
139 ─── cd ~/usr/ports/<pkgname>
140 ─── vim ~/.hm.d/<pkgname>/$USER.h # edit personnal config
141 ─── hm -r <pkgname>/$USER.h # restore user's file
142 ─── makepkg -fi # build package for me
143 ─── hm -r <pkgname> # restore default config
144 ─── makepkg -S # create package for the community
145
146 As the process is always the same, one could create a wrapper script to automate
147 all this even more, but I just don't bother.
148
149
150 And now you don't want to kill yourself anymore when dealing with these kind of
151 software ;)
152 I hope this trick will help somebody. If not, thanks for reading it anyway !