Date: Mon, 10 Feb 2003 12:52:30 +0000 From: Trent Nelson <trent@limekiln.vcisp.net> To: David Leimbach <leimy2k@mac.com> Cc: freebsd-current@freebsd.org Subject: Re: Best method to produce patches? Message-ID: <20030210125230.GA70855@limekiln.vcisp.net> In-Reply-To: <8A57567D-3C7E-11D7-8E7D-0003937E39E0@mac.com> References: <8A57567D-3C7E-11D7-8E7D-0003937E39E0@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Feb 09, 2003 at 04:33:41PM -0600, David Leimbach wrote:
> I am about to try to make some changes to FreeBSD current...
>
> What is the recommend method to use for playing with the source?
I've attached an e-mail from Matt Dillon that gives a very good de-
scription for setting up a FreeBSD development environment.
> Thanks!
>
> Dave Leimbach
Date: Sat, 21 Dec 2002 16:41:23 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
To: Trent Nelson <trent@alcyon-enterprises.com>
Subject: Re: Trying to chase up an old post.
:Hi Matt,
:
: You posted something to current@freebsd.org (or hackers@ possibly)
: just over a year ago describing how you set up your -stable and
: -current environments for doing development.
:
: I've attempted to search for the post, but I'm coming up with false
: hits left right and centre. Any idea which post I'm referring to,
: or even better, can you point me to a URL where it's been archived?
:
: Much appreciated.
:
: Regards,
:
: Trent.
:
:--
:Trent Nelson -- Director, Alcyon Enterprises, Ltd.
I remember making the post, but I don't remember when and I doubt
I could find it in my archives.
Hmm. This would be another good manual page. Maybe I will call
it 'developer' or 'development'. Ok, here we go:
ENVIRONMENT SETUP
Basically I recommend having at least two machines. Run -stable
on your main development system. Create a huge partition called
/FreeBSD. Mine is 12GB (and currently holds 8G of junk in it,
including portions of NetBSD, OpenBSD, and Linux as well as
FreeBSD).
REASON>> This way you can export /FreeBSD to any other machines
you have via read-only NFS without exposing sensitive partitions
on your main development machine.
REASON>> You always want your main development environment to be
on a stable, reliable platform, otherwise you might blow something
up and then not be able to fix it.
Use cvsup (once a night via cron) to keep a local copy of the
FreeBSD CVS tree.
mkdir /FreeBSD/FreeBSD-CVS
ln -s /FreeBSD/FreeBSD-CVS /home/ncvs
cron entry:
20 6 * * * /usr/local/bin/cvsup -g -r 20 -L 2 -h cvsup.freebsd.org /usr/share/examples/cvsup/cvs-supfile
Then use cvs to checkout and maintain a -stable source tree
and a -current source tree. I do this:
mkdir /FreeBSD/FreeBSD-4.x
mkdir /FreeBSD/FreeBSD-current
cd /FreeBSD/FreeBSD-4.x
cvs -d /home/ncvs checkout -rRELENG_4 src
cd /FreeBSD/FreeBSD-current
cvs -d /home/ncvs checkout src
cvs -d /home/ncvs checkout ports
cvs -d /home/ncvs checkout doc
REASON>> Keeping the broken-out source in /FreeBSD allows
you to export it to other machines along with the rest
of the development environment.
Now create a softlink for /usr/src and /usr/src2. I
usually point /usr/src at -stable and /usr/src2 at -current:
cd /usr
rm -rf src src2
ln -s /FreeBSD/FreeBSD-4.x/src src
ln -s /FreeBSD/FreeBSD-current/src src
Put /usr/obj in /FreeBSD as well, or give it its own partition
(at least 4GB is recommended). Example:
mkdir /FreeBSD/obj
cd /usr
rm -rf obj
ln -s /FreeBSD/obj obj
ALTERNATIVE:
(/usr/obj has its own partition)
REASON>> you are going to want to export /usr/obj via read-only NFS
to your other boxes, which I explain in the BUILDING section. If
you want to be able to compile the world and kernels on the clients,
rather then only compiling on your main development box, I recommend
making /usr/obj its own partition to make it easier to give each
client its own /usr/obj (for client-side compiling), or mounting
/usr/obj on the client from the main development server via read-only
NFS.
I usually keep track of ports via CVS and, as you can
see above, a checkedout version can be maintained in
/FreeBSD/FreeBSD-current/ports. However, in order
to be able to build ports on other machines you will
need to change the distfiles subdirectory:
cd /usr
rm -rf ports
ln -s /FreeBSD/FreeBSD-current/ports ports
cd /usr/ports (this pushes into the softlink)
rm -rf distfiles
ln -s /usr/ports.distfiles distfiles
mkdir /usr/ports.distfiles
mkdir /usr/ports.workdir
IN /etc/make.conf add
--------------------------------------
WRKDIRPREFIX=/usr/ports.workdir
--------------------------------------
REASON>> This allows you to export /usr/ports via a read-only NFS
mount. In fact, just exporting /FreeBSD also gives you ports for
free and on your other machines you can simply softlink
/usr/ports to /FreeBSD/FreeBSD-current/ports.
NOT!!! You may want to choose different directories for distfiles
and workdir, but try to make it consistent across all machines
because the softlink for /usr/ports/distfiles is in /FreeBSD and
must be the same for all machines since it is exported from your
master server. IN PARTICULAR, be aware that both the distfiles
directory and the working directory for building ports might require
hundred of megabytes of space in order to build certain ports, like
the openoffice port or the mozilla port.
EXPORTING VIA NFS FROM THE SERVER
Your /etc/exports file should look something like this:
--------------------------------------
/FreeBSD -ro -alldirs -maproot=root: -network YOURLAN -mask YOURLANMASK
/usr/obj -ro -alldirs -maproot=root: -network YOURLAN -mask YOURLANMASK
--------------------------------------
I strongly recommend only doing READ-ONLY exports. This is not only a
security mechanism (nobody can mess with your development source without
actually being on the development machine), but also a safety mechanism...
it is not usually a good idea to accidently modify /FreeBSD via a client,
especially if you are working on several clients at the same time. So
keep the exports read-only.
CLIENT ENVIRONMENT
Other machines... for example, your -current box or any other machine
you have, can import your development environment via a read-only
NFS mount of /FreeBSD:
An fstab entry looks like this:
--------------------------------------
yourserver:/FreeBSD /FreeBSD nfs ro 0 0
--------------------------------------
Each client should create softlinks links for /usr/ports and /usr/src
that point to the appropriate place. If the client is going to be
a -current box, point the /usr/src on the client at
/FreeBSD/FreeBSD-current/src. Otherwise point it at
/FreeBSD/FreeBSD-4.x/src.
(on client)
cd /usr
rm -rf ports src
ln -s /FreeBSD/FreeBSD-current/ports ports
ln -s /FreeBSD/FreeBSD-XXX/src src (XXX the type of environment
you want on the client, either
4.x or current)
If /usr/obj is its own partition on the server then create an NFS mount
in your fstab for it. Again, it should be a read-only mount.
--------------------------------------
yourserver:/usr/obj /usr/obj nfs ro 0 0
--------------------------------------
lf, instead, /usr/obj is a softlink on the server then create the same
softlink on the client.
cd /usr
rm -rf obj
ln -s <SAME_SOFTLINK_AS_ON_SERVER> obj
Make sure the appropriate directories and make.conf entries exist to
allow you to build ports on your client as well. Note that the ports
distribution is not branched, it exists on the HEAD branch only
(i.e. /FreeBSD/FreeBSD-current/ports).
BUILDING AND INSTALLING THE WORLD
On your main development server you can build a -stable world with:
cd /usr/src
make buildworld
You can also build -current on your main development box, even though
your main development box is running -stable (just don't install it
accidently :-)):
cd /usr/src2
make buildworld
When upgrading your main development box, be sure to not accidently
install -current. That's why I have the /usr/src softlink pointing
at -stable
INSTALLING THE WORLD AND INSTALLING KERNELS ON CLIENTS
You can build on your main development server and install on clients.
The main development server must export /FreeBSD and /usr/obj (if /usr/obj
is its own partition) via read-only NFS to the clients.
NOTE!!!>> If /usr/obj is a softlink on the main development server, it
must also be the EXACT SAME softlink on each client. This is because the
absolute paths are expected to be the same when building the world as when
installing it, and you generally build it on your main development box
and install it from a client.
On the client, installing the world is easy if it has NFS mounted
/FreeBSD and /usr/obj (or pointed /usr/obj as a softlink into /FreeBSD
in the precisely the same manner as the softlink is on the main
development box):
(ON THE CLIENT)
cd /usr/src
make installworld
BUILDING AND INSTALLING KERNELS
Building a -stable kernel (on your main development box):
cd /usr/src/sys/i386/conf
config KERNELNAME
cd /usr/src/sys/compile/KERNELNAME
make depend; make
Installing a -stable kernel (typically done on a client. Only do on
your main development server if you want to install a new kernel for
your main development server):
cd /usr/src/sys/compile/KERNELNAME
make install
Building a -current kernel
cd /usr/src
make buildkernel KERNCONF=KERNELNAME
Installing a -current kernerl (typically done on a client)
cd /usr/src (on the client this is typically a softlink to
/FreeBSD/FreeBSD-current/src, but if that confuses
you too much just use the same /usr/src and /usr/src2
softlinks as you have on the main development
server and then cd into /usr/src2)
make installkernel KERNCONF=KERNELNAME
DOING DEVELOPMENT ON A CLIENT, NOT JUST INSTALLING
I strongly recommend that you only mess around with the source on
your main development server. However, you may wish to do buildworlds
and buildkernel's on the clients (instead of on the main development
server) for testing or other reasons.
If you want to be able to compile the world or kernels directly on a
client, the client needs its own private /usr/obj. This could just be
/usr/obj:
cd /usr
rm -rf obj
mkdir obj
Then you can build and install the world and kernels on a client the
same way you would build them on the server.
CVS UPDATING
The advantage of using cvsup to maintain an uptodate copy of the CVS
repository instead of using it to maintain source trees is that you
can pick and choose when you bring your source tree (or pieces of your
source tree) up to date. By using a cron job to maintain an uptodate
copy of the CVS repository, you can update your source tree at any
time as follows:
(on the main development server)
cd /usr/src
cvs -d /home/ncvs update
cd /usr/src2
cvs -d /home/ncvs update
cd /usr/ports
cvs -d /home/ncvs update
It is that simple, and since you are exporting the whole lot to your
clients, your clients have immediately visibility into the updated
source.
-Matt
----- End forwarded message -----
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030210125230.GA70855>