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

[John-Mark Gurney]

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."