Subject: Re: Creating better packager's documentation
To: Thomas Klausner <wiz@NetBSD.org>
From: Roland Illig <email@example.com>
Date: 08/11/2004 18:16:46
Thomas Klausner wrote:
> Packages.txt is getting quite unwieldy, and I don't think that it
> is a good basis for new-comers to learn how to create packages.
> Are some people interested to work on a packager's guide (that
> could live in e.g. wip/*.txt)?
I'm interested. I already started with some ideas myself. First I tried
to guess what variables may be used (read/written/appended/defined) by
both the package and the build system. I also thought about how
variables can be partitioned into groups that can be remembered more easily.
Some groups are:
- commands (SED, AWK, CP, MV, ...)
- package options (USE_*)
> For the ones that don't want to work on this themselves:
> How did you start making packages? What could you use, what did
> you have to find out by asking people or looking at other packages?
I once wrote a Perl script that listed all the variable names that do
not start with an underscore. Currently there are 830 variables. It's
clear that it takes much time to learn all these.
grep -hr '^[A-Z]' *.mk */*.mk |sed -e 's,[^A-Z_0-9].*,,'|sort|uniq|less
During the last months I often grepped through ./mk/ and read a lot, so
I nearly got the idea how the variables are called. But there are some
I would like to rename ALL_TARGET to BUILD_TARGET in analogy to
INSTALL_TARGET. ALL_TARGET may make sense if you know the history of
pkgsrc (just guessing) but I find BUILD_TARGET more intuitive.
I think most of the package specific variables should be moved outside
./mk/ to reduce the complexity of the base system, especially if they
are only used in one package.
Another group of variables are the ones that are only used internally. I
think of *_MK to prevent multiple inclusion and PHASES_AFTER_*. Other
candidates might be *_COOKIE. All these variables should start with an