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
gurney_j at resnet.uoregon.edu
Mon Sep 12 13:20:45 PDT 2005
Robert Watson wrote this message on Mon, Sep 12, 2005 at 19:28 +0100:
> 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.
Nope.. That is why I made buildenv in the first place... After a
buildworld, it makes a user friendly environment to do the normal
config KERN && cd ../compile/KERN && make depend && make -j 4
That most developers are fond of... And you only need to do the buildworld
when material changes are made, not for every change...
That's how I did quick turn builds for arm, when I got tired of going
through buildkernel... Building for different platforms is the same
problem as building for different branches...
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
More information about the cvs-src