I've just upgraded another i386 machine starting with a 1.1 base release
and a sup'ed source tree as of March 22 07:37 GMT.

I would really *really* like to see 'make build' take more of the
obvious dependencies into account.  I.e. if there were required features
added to any tool for the build, take that into account.  Now of course
this does mean that folks who make use of new features must document
this in the 'build' rule set, and I fully realize that the person who
adds the new feature may not be the person who uses the new feature in
the source tree, and indeed may not realize the feature is new enough to
require such dependency fixing.

In any even I think it would be of paramount importance for final fixes
to be made to the 'build' rule set during the release procedure to
ensure that simply typing 'make build' will always upgrade a previous
binary release to the new release from source without worry.  This is
indeed easy enough to test, provided you have a spare machine on which
the previous binary release can be installed, and obviously at least
some of us are able to do this.

I do hope to further test these procedures by making my own fixes to the
'build' rule set and attempting to upgrade a sun3 (and possibly a sparc
too).  Having to type 'make build' only once for the sun3 is going to be
incredibly important, considering how long it is going to take!  ;-)

Anyway, on with my current (pun intended! ;-) observations:

1. I started with a 'make build', which quickly failed.  ;-)

	cd /usr/src
	make build

2. some new makefile uses 'tsort -q', which seems to be a new flag for
tsort, so:

	cd /usr/src/usr.bin/tsort
	make install
	cd /usr/src
	make build

3. libg++ won't build (needs new gcc, which needs new yacc) [you really
only need to run 'make install' in gnu/usr.bin/gcc twice, but I wanted
to re-build the new compiler with itself]:

	cd /usr/src/usr.bin/yacc
	make install
	cd /usr/src/gnu/usr.bin/gcc
	make install && make install && make cleandir && make install
	cd /usr/src
	make build

4. groff fails to build because of -Werror.  No doubt there's an easier
way to do this:

	cd /usr/src/gnu/usr.bin/groff/pic
	g++ -O -I. -I/usr/src/gnu/usr.bin/groff/pic/../include -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_STDLIB_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_CC_LIMITS_H=1 -DHAVE_CC_UNISTD_H=1 -DSTDLIB_H_DECLARES_GETOPT=1 -DUNISTD_H_DECLARES_GETOPT=1 -DSTDLIB_H_DECLARES_PUTENV=1 -DRETSIGTYPE=void -DHAVE_MMAP=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DHAVE_SYS_SIGLIST=1  -Werror  -c pic.cc
	cd /usr/src/gnu/usr.bin/groff
	make
	cd /usr/src/gnu/usr.bin/groff/eqn
	g++ -O -I. -I/usr/src/gnu/usr.bin/groff/eqn/../include -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_STDLIB_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_CC_LIMITS_H=1 -DHAVE_CC_UNISTD_H=1 -DSTDLIB_H_DECLARES_GETOPT=1 -DUNISTD_H_DECLARES_GETOPT=1 -DSTDLIB_H_DECLARES_PUTENV=1 -DRETSIGTYPE=void -DHAVE_MMAP=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DHAVE_SYS_SIGLIST=1  -Werror  -c eqn.cc
	cd /usr/src/gnu/usr.bin/groff
	make
	cd /usr/src/gnu/usr.bin/groff/refer
g++ -O -I. -I/usr/src/gnu/usr.bin/groff/refer/../include -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_STDLIB_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_CC_LIMITS_H=1 -DHAVE_CC_UNISTD_H=1 -DSTDLIB_H_DECLARES_GETOPT=1 -DUNISTD_H_DECLARES_GETOPT=1 -DSTDLIB_H_DECLARES_PUTENV=1 -DRETSIGTYPE=void -DHAVE_MMAP=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DHAVE_SYS_SIGLIST=1  -Werror  -c label.cc
	cd /usr/src/gnu/usr.bin/groff
	make

And this time it builds fine, so we start over at the top again:

	cd /usr/src
	make build

5. ln fails to install due to a very weird shell bug (it fails when
called by make, but works OK when typed on the command line).  The
failed command and error message are:

install -c -o bin -g bin -m 444 symlink.cat7 /usr/share/man/catsymlink.cat7/symlink.0
install: /usr/share/man/catsymlink.cat7/symlink.0: No such file or directory
*** Error code 1

Re-install /bin/sh (which indeed fixes the above) and start again:

	cd /usr/src/bin/sh
	make install
	cd /usr/src
	make build

Everthing is OK now -- including a very -current kernel!

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>