Subject: Re: CVS commit: src
To: Scott Reynolds <scottr@og.org>
From: Ted Lemon <mellon@isc.org>
List: tech-misc
Date: 02/20/1999 18:40:49
First of all, I will say that in context, your point is valid, so what
follows is an argument for what should be, not a justification for
putting that extra build target in make build.   I did that because I
was thinking of my own usage model for make build, and not considering
yours.   You were right to back it out.   However, ...

> Historically, the top-level Makefile's `build' target has been used by
> people who are keeping close tabs on the development of the system.

Historically, ``make build'' is used by everybody who tracks -current.
Some people build every day.  Some build once a week.  Some build once
a month.  Some build whenever they do a new install (that's me!).
There is no one single kind of customer for ``make build.''  Consider:
is it an accident that you identify the most important customer for
``make build'' as yourself?   I don't think so - I think we each see
this problem from our own equally valid perspective.

> Anyway, back to the primary point.  We frequently have `update libc',
> `update lex', `update rpcgen', and similar one-time prerequisites for a
> build.

Yup.

> I maintain that it's unreasonable to dump every single one of
> these into the top-level build target.

I don't agree with this.   I do agree that it's unreasonable to force
a frequent make-builder to do this every time, but I *don't* think
it's unreasonable to solve the problem in a way that serves both of us
well.   Announcing that you have to update *whatever* on current-users
only helps frequent builders like you - I don't remember that stuff
three weeks or two months later when I do a make build, and arguing
that goddammit I should is not helpful.

The right solution to this problem, which I am merely proposing here
and not suggesting you implement, is that the top-level makefile
should maintain a registry in /var/pkg or somewhere like that of what
version of utilities like this is installed.  When you do a make
build, it should check a list of prerequisites, and rebuild and
reinstall anything that's out of date.  When somebody makes a change
that creates a prerequisite for future builds, that should be encoded
in the Makefile.  When somebody stumbles over a change like this that
the changer forgot to encode, he or she should encode it in the same
way.  This will add a small amount of time to your m68020 build, but
it shouldn't be significant, and it will also enable infrequent
updaters to win without major anguish when they update.

			       _MelloN_