Hello everyone,

Having a little free time on my hands I tried building a current
kernel this morning. Builds hadn't worked for some time (ncr_something.h
missing somewhere) so I got me a new sys.tar.gz, a new include.tar.gz,
and a new config.tar.gz. The include-files refused to install
though, so I had to get share.tar.gz to install the /usr/share/mk
files. Which didn't install, so I had to get a new make and install.
Which, by the way, didn't install because I had to set BINDIR in
the makefile.

This is not the first time I've been through this, so most of the 
problems weren't that hard to figure out. But given that we have the
tools to prevent them, why do we need to go through this hassle?

I'd suggest adding a new category to sup, "kern-depends" e.g., that
will track all the files needed to build a kernel. This ought to 
include make, config, /usr/share/mk, and the system- and kernel- 
includes. The makefile that gets generated by config for the compile-
directory ought to check whether make, config, etc. need to be rebuilt/
reinstalled and if so, either prompt the user to do this, or do so itself.

This would also be a convenient place to trigger rebuilding ps, systat
and other kmem-group binaries when the makefile detects changes in the
kmem-part of the kernel-source. If neccesary, these programms could be
included into the kern-depends sup-category.

Lastly, I would suggest adding something like "if $BINDIR is not set,
set it to wherever this binary should go" to all makefiles, so it
becomes easier to make and install single programms without having
a complete source-tree at hand.

Would this be considered a good way to solve the problems I mentioned
above? What do you all think?

Regards, Paul.
-- 
----------------------------------------------------------------------
Paul Boven, <e.p.boven@student.utwente.nl>  PE1NUT  QRV 145.575 JO32KF
          Lynx users have a "Right to follow a link", too!
----------------------------------------------------------------------