[BusyBox] Improving Our Development Process

[Gennady Feldman]

On Tue, 23 Jan 2001, Erik Andersen wrote:

> [clipped]
> Hmm.  I think this is a good idea and I think we can extend it
> much further.  I am not very fond of the current state of things
> where we have 120 something C files in one flat directory.  It
> would be nicer to split things up into a bunch of logical blocks,
> i.e.  fileutils, shellutils, etc.
>
>  -Erik

I propose the following directory structure to start from:

 busybox (main directory containing all the files could be busybox-0.50
 |        also could be created when extracting tar.gz file)
 |
 \ doc   (contains all the documentation files)
 |
 \ src   (contains all the source files)
  |
  \ busybox  (busybox part of the package)
      |
      \ fileutils    (sections added as proposed by Erik)
      |
      \ shellutils   (sections added as proposed by Erik)
  |
  \ netkit-tiny (netkit-tiny part of the package)
  |
  \ others?? tiny-login?

 compilation:
  busybox\Makefile 	would do a make -C <dirname> for all the subdirectories
			which would compile/generate all the documentation
			and binary files

  busybox\doc\Makefile	would generate the documentation

  busybox\src\busybox\Makefile busybox Makefile

  and so on...

 The only confusing thing is how are we going to track the selected
applets to compile and how many Config.h files will we have?

  README, LICENSE and other files go into the root directory. This is
actually a somewhat standard file/directory layout for many projects.

 The only remaining issues are:
 - Are we going to start re-organizing the CVS tree to confirm w/ the new
directory layout (we could also create a new branch and tag the old one
for reference)
 - should we have MAINTAINERS file w/ lists of who is maintaing what
file(s) in this subdirectory and where patches should be directed to for
testing/approval?
 - I can start prototyping or helping out on getting the new directory
structure in place that is if we decide to go in this direction.
 - The issue of selecting which binaries/applets are going to be compiled
is a complicated one, should we write a program/script something like
menuconfig in the linux kernel to do binary/applet selection?
 - Also on the plus side we could create >2 binaries. For example we could
split out SH as a separate binary file for the interactive shell. This
would let us use it in our regular environment, which in turn is going to
give it sufficient testing and patches/improvements. Since it's a separate
entity and a rather complicated one we could just let it be compiled
either separately or into the main busybox executable.

P.S. What do you guys/gals think about this?

G.F.