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_