> By examining the history of the build target, it is clear that using it 
> for anything other than frequent builds has never been supported.

That is not the way I interpret the history of the build target.   I
suspect that this is a somewhat subjective process, though, so it's
unlikely to help us to arrive at an agreement as to the actual truth
of the matter, if such a thing exists... :'}

> Since the majority of the user base runs releases and does not track
> -current, this is relatively reasonable.

I have no idea what the majority of the user base does.  I do know
that a _lot_ of people track -current, generally not on a daily basis.
Perhaps it is only because I am one of their number, but I think their
needs are significant and should not be dismissed out of hand.
Nothing you have said argues to me that this group is outnumbered by
or is less important than the group of people that do daily builds.

> I find it quite interesting that you interpreted it that way.  The
> fact of the matter is that I am personally part of the frequent
> build group only a week or two out of every 2 months.  There are
> others, however, that do daily and weekly builds.

So it appears that you use the make build target almost exactly the
way I do - the only difference is that you do a number of make builds
in quick succession after the first.  Actually, that's usually what I
do to, since there are usually a few trivial inconsistencies to
resolve.  Admittedly, I do not do these builds on m68k targets.

This begs the question, though: who are these customers of the target
that are different than you or I?  Why are you arguing for an
interpretation of what make build is used for that is different than
the way you actually use it?

I apologized in my previous message for thoughtlessly increasing the
length of make build.  You have backed out my change.  I think that
problem is solved.  I am also sorry that I presumed something about
you for the purposes of rhetorical emphasis which wasn't true.

> Interesting, should work, but how about something that's far simpler to
> implement and doesn't require a ton of infrastructure?  Create an
> `upgrade' target that builds the prerequisites, then does a `${MAKE}
> build' as the last step.  (This target would probably not do anything for
> a non-root DESTDIR.)

This would certainly be a good start.

I think having versioning on build tools would actually be a good
thing in itself, as part of a more customizable install and upgrade
process, so I still think the solution I proposed is a better
long-term solution, but I do agree that it's more complex.  :')

			       _MelloN_