1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
|
#!/usr/bin/less
Thing(y) 0.1 -- This Hack Is Not GNU (yet?)
The name seems really... noobish right now. The idea was that I would
fork several GNU projects, to experiment with new features, then worry
about getting them merged back into mainstream GNU later.
This sounds dumb right now because, well, Thing doesn't include any
GNU-based packages right now. Right now it is my tinkering with
making new build/mangagement tools, perhaps one day I will use them to
work on GNU packages, or get them merged.
I like the name because
a) it's ambiguous/random
b) the `y' at the end is optional. Sometimes I use the `y' to
hint at how much I expect it to become part of GNU
c) It's a refference to GNU's own name.
The reason it's significant that it's `not GNU' is because
I differ from GNU design principals in a few places.
Getting them merged into GNU would sometimes even require
an ammendment to the GNU Coding Standards. Although, it's
moot, because I still haven't done any GNU hacking.
Anyway, right now Thing is mostly a build system... the one Thing
uses. I had all these (unrelated) packages, and I was tired of
patching the config and Makefiles with general changes. I got sick of
them being different, and hard to manage. So I started refactoring
them to be on the same build system.
=How the build system works=
`Makefile' in the top directory is a file you will use, but packages
won't know it exists. It offers several commands that can be used
to build packages:
complete-PKG_NAME - each package is not complete, there are
several files generic to all packages, this
completes the package
distclean-PKG_NAME - make that `distclean'. Actually, more
than distclean, it removes generic files
placed there by `complete-PKG_NAME'
build-PKG_NAME - build the package in the separate directory
`PACKAGE_NAME-build'.
This depends on `complete-PKG_NAME'.
This works by calling that package's Makefile
install-PKG_NAME - runs `$(MAKE) -C PKG_NAME-build install'
clean-PKG_NAME - runs `$(MAKE) -C PKG_NAME-build clean'
complete-PKG_NAME
* This copies the following files from this directory into the
package's directory:
* configure
* COPYING
* Makefile.in
build-PKG_NAME
(depends on complete-PKG_NAME)
(`$srcdir' by default is the directory containing configure)
* This creates and cd into the directory `PKG_NAME-build'
* It runs `../PKG_NAME/configure'
* It sources the file `$srcdir/config' if it exists. This
allows for package-specific configure stuff to happen
* It scans $srcdir and subdirectories for any files with the
names:
Makefile.in
*.mk.in
* It goes through the standard Autoconf fare on these files,
and places the resulting files in the coresponding files
in `PKG_NAME-build', sans `.in'
* It runs make in the `PKG_NAME-build' directory
Yeah, this means running the generic `Makefile' generated from
`Makefile.in'. So, how do you actually get things to build?
It sources/includes `main.mk'
The generic Makefile provides several generic functions:
* target `Makefile': remakes all Makefiles
* Also generates a `*.d' file for each `*.c' file,
containing dependancies on #included header files.
* target `dist': creates a .tar.gz of the package
* target `distclean': cleans all files. This LEAVES generic
files
|
