cvs commit: src/sys/kern kern_tc.c src/sys/net rtsock.c src/sys/netipx ipx_proto.c src/sys/netnatm natm_proto.c

[Robert Watson]

On Mon, 12 Sep 2005, David O'Brien wrote:

> Suppose that thru a long multi-month discussion with the TRB and parts 
> of Core a matrix was created what was officially supported of what 
> builds on what.  And also stated what was should be kept building on 
> what if reasonable to do so.  And stated what wasn't supported.
>
> The build situation you championed wasn't even contemplated - it isn't 
> one we'd run into to even consider having it in the matrix.
>
> I know for a fact that a RELENG_5 config(8) won't config a -CURRENT 
> kernel.  So you must have built a -CURRENT config(8) on your RELENG_x 
> box (or be prepared to).  You could also build -CURRENT gcc+binutils on 
> your RELENG_x box and install it for use in building HEAD kernels.

So it would appear:

zoo:/zoo/rwatson/p4/projects/netsmp/src/sys/fs/fifofs% ls ~/bin
./              config4*        config61*       ministat*
../             config6*        config62*       p4*

Easy to do it with config, a pain to do it with a complete toolchain.

I have to say that the NOMAN->NO_MAN changes last year were among the most 
annoying of this sort we've had in ages, since there was little or no 
effort at forwards compatibility for builds.  This required custom 
modification of the module Makefile for aic7xxx for every kernel source 
code tree I work with, which was also a waste of time.

>> On my desktop (P4 1.8GHz, 512MB), it takes 15 minutes per kernel tools 
>> build, which assuming I built them on the three machines sequentially, 
>> would result in spending 9 hours rebuilding kernel tools as a result of 
>> introducing dependencies on compiler tweaks before merging them.
>
> Honestly, a 1.8GHz Intel (or AMD 1800+) desktop CPU is 4 years old. 
> For some one building 12 active branches a day, I think you would be 
> more than justified in asking for a more powerful desktop at 
> http://www.freebsd.org/donations/wantlist.html With both Intel and AMD 
> have dual-core desktops - allowing you to have a cheap SMP machine, its 
> a good time to ask on wantlist.html.

While the build time is huge, it's much more the management time that 
makes it an issue: as I said, keeping 12 branches with in sync toolchains 
is very time-consuming, and adds overhead to day-to-day development that, 
in the general case, is unnecessary.

>> So the difference between it working may be gravy to you, but it's the 
>> difference between spending several days of my FreeBSD time chasing 
>> build tool changes over a dozen branches and several machines and 
>> spending those days doing productive work.  Which isn't to say that 
>> progress shouldn't happen, just that a minor change in the order of 
>> commits would have saved me a lot of time.
>
> There are 100's and 100's of FreeBSD commits that if ordered or done 
> slightly differently would have saved me hours and hours and hours. 
> That, unfortunately, is the life of a committer in FreeBSD'ville.

No doubt.

Yet you'd think that avoiding unnecessary inconvenience would be something 
you'd consider desirable, given that...

Robert N M Watson