[ On Mon, March 25, 1996 at 23:04:50 (-0500), Chris G. Demetriou wrote: ]
> Subject: Re: another 1.1 to 1.1B (i386) upgrade report... 
>
> It's quite easy to get into a situation where 'make build' just can't
> do this...  (e.g.: need new config to build new kernel, need new libs
> for new config, need new kernel for new libs.)

I agree there are cases where there are kernel dependencies, though for
the life of me I can't think of any which would (or more correctly
should) directly affect the build process.  I.e. we've a running system
of version X, and the sources available for version X+1, so we shouldn't
need to do anything but type 'make build' and stand well back.  In fact
we should be able to say 'make DESTROOT=/new build' and not affect the
running system at all, but I think that's maybe asking a bit too much
from folks who are not accustomed to thinking with at productisation
mindset.

> This is _exactly_ what binary snapshots and upgrades are for.

I wish there were indeed more of these available, esp. by CD-ROM.

> Please, don't crowd 'make build' with this, and don't change the
> top-level makefile as often as would be necessary to make this work in
> the few 'serious' cases where it's actually possible.

I should think we could at least support the "obvious" cases.

Compiler tools and library dependencies would be an obvious first step.

I note that the libraries, header files, and shared make rules are
indeed already handled (i.e. part of the reason for 'make build' in the
first place).  We now (finally) have a new compiler, and I think it
would be a terribly good idea to ease the transition for the majority of
folks, esp. given the number of problems that seem to continually be
reported in current-users.

The next step might be to ensure other build tools are installed in some
reasonable order, such as make, ld, ar, tsort, as, etc., etc.

Beyond that I agree that certain things can get tricky.  My recent
upgrade would have been far more difficult had I required NFS, for
example.  However I expect that handling the obvious configurations (a
recent working system everything in the normal places, esp. source in
/usr/src, all local disk, nothing upgraded out of sync, etc.) will
suffice.

If this weren't something that many of us trip over every time something
obvious changes, I would agree and even go so far as to say that 'make
build' is entirely useless.  However given my own experience, and the
multitude of times folks report troubles in current-users, I don't see
how you can suggest that even the obvious and trivial things not be
taken care of once and for all.

I'm also raising this point (again), in hopes that it be resolved such
that there can be a distributed procedure available to permit source
upgrades to the next release.  I.e. not something that would only be of
interest to current-users, but something which might help the average
1.1 user who did a binary install way back when and who now wants to try
building from the source.  I see no reason why the build procedure
should require that user to first obtain and install a new binary kit.

After all, this isn't anywhere as complex as doing a 'make build' from,
say, SunOS-4 and expecting it to self-install.  ;-)

Indeed it does mean that people will have to think in terms of the
broader implications of changes they make, and it will require a
non-trivial amount of testing.

Might I also point out that last time I raised this issue there was no
'make build' at all.  Further at that time there was a prominent
current-users person submitting regular build reports that made it much
easier for a current-users reader to catch up to the state of the art.
There is no such regular report now.

I commend the initial attempt at 'make build' and only ask that it be
improved to at least handle simple-case source-only upgrades from
release to release.  If this is done in an incremental way, it may even
help current-users readers work with the catch of the day.

-- 
							Greg A. Woods

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