Building a sandboxed kernel

R. Tyler Ballance tyler at
Sun Jul 23 10:52:49 UTC 2006

Hash: SHA1

>> Between varying versions of userland tools (like config(8)) and path
>> troubles, I'm wondering what tips anybody has to doing non-standard
>> builds of the kernel (non-standard being not in /usr/src and not the
>> host arch)
>> Currently the make command I'm using, which doesn't work, is (/usr/
>> obj is chmod'd 777):
>> make TARGET_ARCH=iguana DESTDIR=/home/tyler/iguana buildkernel
>> Any suggestions?
> You don't have to use /usr/obj for all your builds:
>     % mkdir -p /home/tyler/obj/iguana
>     % env MAKEOBJDIRPREFIX=/home/tyler/obj/iguana \
>       make TARGET_ARCH=iguana \
>            DESTDIR=/home/tyler/iguana \
>       buildkernel
> The trick here is to use MAKEOBJDIRPREFIX to change the default object
> directory prefix from `/usr/obj' to whatever suits your own setup.

This doesn't solve the problem of different versions of userland  
tools required. For example, my machne is RELENG_6, but I'm  
developing against the -CURRENT branch of code synced up in perforce.  
Does one necessarily need a -CURRENT userland to develop with the - 
CURRENT code base? All arguments of being able to test the code that  
is built are moot since the testing of my code will all occur within  
a virtualized (Qemu) machine environment.

I'm sure the difference in versions between RELENG_6 and CURRENT  
aren't too great, but what about developing with CURRENT code on  
RELENG_5? I guess the basic question is, how can I maintain my normal  
workstation environment while using a toolset appropriate for  
building CURRENT? (Does it even matter really?)


- -R. Tyler Ballance

Version: GnuPG v1.4.3 (Darwin)


More information about the freebsd-hackers mailing list