While documenting the source tree layout...
Rob Landley
rob at landley.net
Sun Jan 15 19:52:24 UTC 2006
So I'm hanging around the Chicago airport during a 4 hour layover, writing
documentation (programming.html) and reading the source code. (I'm trying to
document the layout of our source tree, and that means I'm looking at the
layout of our source tree. A certain amount of head scratching is going on
here.)
Would someone please explain to me what the following directories are for:
1) debian
No, this isn't deban-utils, this is build scripts, variant configurations, and
packaging stuff for the use that debian made of busybox about three years
ago. I'm all for debian using busybox, but why on earth does the busybox
tarball contain three year old copies of debian-specific config files? (Are
we going to accumulate obsolete versions of config files for Red Hat, puppy
linux, tomsrtbt, and everybody else who ever used us?)
I say nuke this directory.
2) libpwdgrp
It seems to me that this should either be in loginutils or in libbb. Why is
this in its' own directory? It contains two files, one of which is fairly
big (25k) but hash_fd in libbb is almost the same size.
I'm happy moving it to either one, but it probably shouldn't stay where it is.
3) patches
Either we apply patches to the tarball or we don't check them in, this strange
halfway state confuses me. (I know we've culled this directory down from
where it was, but we should get rid of what's left of it.)
We should clean it up and nuke it.
4) sysdeps
I know we copied our config from the linux kernel, but having TARGET_OS in
rules.mak and using it the top level Makefile to find Config.in and defconfig
is kinda silly. Right now busybox is highly linux-centric and if we decide
to move away from that we shouldn't do it by adding special cases for other
operating systems but instead trying to move towards posix and susv3 to
become more OS agnostic. (Which I don't really think is that great an idea
because all sorts of stuff like losetup and fbsetup isn't in any standard I
can find. Heck, if somebody can find a standard for _init_ I'd be happy...)
In any case, gratuitous infrastructure for something we aren't even planning
to do yet is unnecessary complication and overengineering.
Nuke this directory. These two files should either live in scripts/config
along with the rest of the configuration infrastructure, or they should be at
the top level of the tarball. (No strong preference either way.)
5) scripts
The name's misleading. This directory contains two things (scripts/config is
our copied and modified version of kconfig, and bb_mkdep.c is vodz's
dependency checker), both of which are configuration and build
infrastructure.
A nice cleanup would be to move bb_mkdep.c into scripts/config, and then move
that up one level and essential turn the "scripts" directory into "config".
---------------
That leaves us with seven infrastructure directories (applets, docs, examples,
include, libbb, scripts/config, and testsuite) and sixteen applet directories
(archival, console-tools, coreutils, debianutils, e2fsprogs, editors,
findutils, init, loginutils, miscutils, modutils, networking, procps, shell,
sysklogd, and util-linux).
One other wild idea would be moving the 16 applet directories under
"applets" (ala "applets/init/init.c"), since we've developed rather a lot of
code and grouping it sanely might be nice...
Rob
--
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word.
I do not think it means what you think it means.
More information about the busybox
mailing list