> Doesnt using /etc/make.conf for buildworld configurations
> only makes sense when you are building a new world on the
> system you plan to install it on.
> Think about buildkernel for a minute.
> I like building different kernels for different hardware on
> my network. I build the different versions on one box:
> #make buildkernel KERNCONF=myconfig0
> #make buildkernel KERNCONF=myconfig1
> This works well because I put my kernel compilation overrides
> (NO_MODULES say) into the kernel config file. I build as many
> as I want, and then I can install them on the desired machine
> and it no way affects my current machine.
> I dont touch /etc/make.conf for kernel builds.
> There ought to be an equivalent for buildworld that goes:
> make buildworld worldconf=w1.conf
> make buildworld worldconf=w2.conf
> So I can keep my "world configs" seperate.
The difference between building kernels and building world is
that "make buildworld" wipes out /usr/obj, i.e., you don't
generally store a bunch of "worlds" on your system at the same
time, whereas you may store a bunch of alternative kernels, or
build a kernel for a slow machine on a fast one, move it, etc.
Quote:> If you plan on building multiple worlds for other systems
> (and dont want to rebuild your current system) are you
> supposed to save a copy of your current make.conf, change
> it before you build each destination world, and change it
> back later?
Okay, how are you going to install them? I read a while ago
something Matt Dillon wrote about nfs installs, and as I recall
he recommended that /usr/src and /usr/obj be mounted as such
(no symlinks etc) on the target machine. So, one world at a time,
right? (But see below--you can put the output different places.)
I have successfully done an nfs install--actually on a laptop
running FreeBSD in vmware (running in Win2k)--following Matt's
directions (which I think were on the -stable mailing list). In
fact some people regularly install via nfs in this way, running
the buildworld only once on the source machine, since they are
installing on many identical machines.
Quote:> The idea of make.conf for buildworld is right. But
> keeping it in /etc has got to be wrong. Right?
> Am I missing something here?
I guess if I regularly wanted to do a buildworld for alternative
machines, I'd write a script for each and keep it in $HOME/bin.
It would first cd /usr/src (because make reads the Makefile in the
directory from which it's called) and then use make buildworld with
whatever options on the command line I happened to want (this command
line being part of the script).
You could also have scripts that move the appropriate /etc/make.conf
into place for whatever configuration you wanted to use to build world.
I think this would be messier though.
You could also write makefile to include with the -f option, and keep it
in /usr/src, but the -f option overrides, as I understand it, the default
search for a makefile, so you need to make -f Makefile -f makeworld1 so
that the basic Makefile (and whatever other makefiles it incorporates
via .include statements) gets read first.
I think the script that cd's to /usr/src and then runs make buildworld
with appropriate options is probably the best way to go. One option
would be the place where the object files...so on the fast machine with
huge amounts of disk space (at least 350MB per world) you could have a
bunch of different output directories (with their subdirs) that are then
mounted on the target as /usr/obj for installation (make installworld)
along with /usr/src from the "source" machine.
All that said, "make" is complicated and whatever you do, you want to
test it first to make sure (no pun intended) you get what you expect
(and read appropriate man pages first).
Annelise
--
Annelise Anderson
Author of: FreeBSD: An Open-Source Operating System for Your PC
Available from: BSDmall.com and amazon.com
Book Website: http://www.bittreepress.com/FreeBSD/introbook/
by