Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 27 Aug 1996 06:52:09 -0500
From:      rkw@shark.dataplex.net (Richard Wackerbarth)
To:        Paul Richards <p.richards@elsevier.co.uk>
Cc:        hackers@FreeBSD.org
Subject:   Re: Am I wrong or is this just stupid?r
Message-ID:  <v02140b04ae488b282b38@[208.2.87.4]>

next in thread | raw e-mail | index | archive | help
Paul Richards <p.richards@elsevier.co.uk> replies:

>rkw@dataplex.net (Richard Wackerbarth) writes:

>> We would probably want to have 3 conditions.
>> 1) Unconditionally build the tools
>> 2) Test to see if the tools are up-to-date
>> 3) Assume the tools are up-to-date as of the time of the cookie.
>> This can be done with two tokens, "tools_built" and "tools_changed".
>
>This is all ridiculously complex for a relatively rare occurence these
>days.
>
>An upgrade of the tools does *NOT* imply that a bootstrap
>stage is required. We're talking about different problems here. I
>think an explanation of the historical reasons for the current setup
>is required for those who weren't around.

I tend to agree. However, there are those who persist in the notion that
they "must" have the bootstrap phase AUTOMATICALLY included.

Setting up the mechanism is not all that difficult and it does allow us to
"keep the troops happy".

The biggest problem that I have with doing ANYTHING to the "make" structure
is that there is no concensus building. Anyone who proposes a change is
immediately "shot down" by someone who refuses to allow progress if it
means that he has to CHANGE anything about his favorite mode of operation.

There are certainly arguments as to why each of the three above mentioned
targets are of value. Exclusive use of (3) leads to missed changes to
things like "config". In the typical case, (2) is more time consuming than
necessary.
Case (1) COULD be handled by manual bootstrapping, but that is "too hard"
for some HA's.

It appears to me that many of the "hackers" have never worked on a large
shared system or with cross compilers. When you have your own private space
and are only making minor changes to a single native implementation, you
can get away with "shortcuts" that don't work in the general case. It IS a
little harder to set things up to handle the general case, but once it is
done, it is NOT more difficult to use. However, before any real progress
can be made, people need to break out of the mentality trap what prohibits
change.






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v02140b04ae488b282b38>