Adventures in tinderbox 2

If you stumbled into this post first you may want to have a look over this previous post as we are building upon steps covered there.

So far we have got our world binaries built and these are the foundation of the environments we setup for testing our port builds. From here we create a tinderbox build. Within tinderbox a build refers to a combination of world binaries (the tinderbox jails we setup before) and a version of the ports files. It is probably a rare case but it would appear that you could setup a build using say netbsd pkgsrc system or similar, the most likely alternative to the official ports system would be an internal development branch of the ports source.

The first step is to setup the ports files to be used. A cvs checkout is shown in the docs and you could adjust the svn usage from yesterday if you have your own local svn repo (official ports are still in cvs at this point). The examples in the docs show a source checkout that is unique to your tinderbox setup. I think using the system installed ports will be enough for what I want and will bypass the confusion of three copies of the ports files. Personally I use portsnap to update my system ports tree and create or update a port there to test and develop it. Then I have a copy within my home folder that is an svn checkout from my redports account that I transfer changes to that I want to keep, and commit as desired from there. While my personal folder is just the ports I make changes to, I don't want a third copy just for test builds, so what I will use here is a user defined update method that will run portsnap anytime I want to update the ports tree. We have two options here, 1. create a portsTree with no update method leaving us to run portsnap manually as desired. 2. create a portsTree with a user update method. The first option is straight forward and acceptable for most but I want to look at option 2 here.

Reading the docs you may jump straight in and use a command like cd /usr/local/tinderbox/scripts ./tc createPortsTree -p FreeBSD -u USER -m /usr/ports and get errors and no ports tree setup. The docs don't help here so I went digging through the scripts and found the answer. When you create a portstree with a user defined update method it looks for the update script when it is first setup. The solution is simple. If we are creating a portstree called FreeBSD then we create a file in tinderbox/portstrees/FreeBSD and call it update.sh and for this example I want it to run portsnap so I use the following contents - #!/bin/sh portsnap fetch update Then run the createPortsTree command with the -u USER option. Simple and a good basis of any custom update you want to setup. You could even use this to run portsnap and then merge files from your personal ports repo automatically. This setup script is run with the command ./tc updatePortsTree

You may also want to share your local distfiles with tinderbox. Pretty easy and the one setup is shared across all portstree configs -

Now that we have our jails and portsTree setup it is time for the build. Remember a tinderbox build is a combination of a specific jail and portsTree and is straight forward -

The name I used there may raise a few questions but first lets consider what variations of builds we want to use.

The aim of using tinderbox is to test building under a variety of conditions, in this case primarily different system versions. To that end we started by creating 2 jails with different versions of world binaries, you may have extended that number and I encourage you to do so but I use two in these examples. From FreeBSD 9.0 we are moving away from a  dependency on gcc as the main compiler and now include clang within the base system. Being in the early transition of this is a bit awkward as not all ports build with the old gcc v4.2 that is included with base and not all ports build with clang either. Well ports changes need to be tested with each compiler so we may get a full ports build happening on any system install. One option we have is to specify what version of gcc is used to build our port. Easy till we get linking issues with something like boost installed with gcc42 and not linking with a gcc46 built port (that is my early guess and may not be the location of a solution). So anyway I am suggesting that a number of builds are setup to test building with clang as well as gcc. This will only apply to 9.0 and higher, 8.3 has just entered beta1 and doesn't appear to include clang. The other question you may have is that I only put clang in the name, how does it know to build with clang? It doesn't yet - that comes in a minute.

Well using the two jails we built yesterday lets setup the builds -

Now we have four builds setup to test our ports in. As I suggested before you should also consider having at least an 8-STABLE jail setup and maybe even a 7-STABLE one as well if not more. As clang is not included in 7 or 8 there is no need to setup two builds for each, I would still use gcc in the build name though.

At this point you will find a few directories have been created. The first you will probably see is tinderbox/{BUILDNAME} so if your following along you will have four there corresponding to each build you setup. The next ones are inside tinderbox/builds and have the same names as the four we just looked at. The dirs inside builds contain a Makefile with all the package  dependencies and although you may think make.0 and make.1 are makefiles they are in fact logs containing the log of the last compile done, each port compile is run in two phases, and a more than likely empty duds file. The top level dirs are where all the work is done. For each port you make, tinderbox will extract the tarball found in the corresponding jail build and mount the various points needed for portstrees/distfiles/devfs/procfs. From that you can work out that each build starts up in a unique environment (it uses chroot) completely isolated for your test make. Each environment is cleaned up after each test make and the log files will include files left behind if you get your pkg-plist incorrect.

Now to configuring the compiler to use. When you first test making your port and look at a log file you may notice that the timestamp at the start is all wrong. That will be a wrong timezone setting and gets us close to the compiler settings. First lets set the timezone, so edit the file tinderbox/scripts/etc/env/GLOBAL and add the following line (adjusted to match your timezone of course)

You can see that it uses a bash style environment setting. Within the same folder we want to create a config file for each build we setup using the name build.{BUILDNAME} and have it contain the CC options that we wish to use. Before you go thinking about copying all your /etc/make.conf settings consider the purpose of this - testing against a minimum system config to ensure your port is as compatible as possible. Those with a custom edited make.conf need to handle their own port build conflicts with the options they want to use. So here all we want to do is set the compiler to use. To make this easy let's make a script, I will put this inside tinderbox/scripts and lets call it gencompilerenvfiles.sh

Pretty straight forward if you know some shell scripting, if it's a bit beyond what you know it simply gets a list of dirs from within builds and outputs three lines to a corresponding config file for each one. The script won't touch files that already exist, so delete them if you want a clean slate or adjust if you want to add to existing files. The first loop uses grep to get clang named builds the second gcc. Is it overkill specifying gcc for the gcc builds - yep - but it keeps things consistent and also gets the CC setting output to the log file to remove any confusion when looking over them later, or more to the point when you get someone else to look over them for some help.

Now your all setup to use tinderbox to test your ports building. While the docs say you can do an adhoc build with just the tinderbuild command I find that not to be the case, the two command you use are

The first time you build a port it may take a while - it will build each  dependency needed, basically running make package-recursive for your port. Next time it will just pkg_add each dependancy and build the port you ask it to. The -nullfs option is needed if you setup the nullfs mount for portstree as shown above (or maybe it is for distfiles?). This adds some more dirs for you as well.

tinderbox/packages/{BUILDNAME} will contain all the packages created by that build. You will find a folder for each category containing links to the corresponding package inside the All dir.

tinderbox/logs/{BUILDNAME} will contain log files of each port compiled for that build.

tinderbox/errors/{BUILDNAME} will contain copies of the log files that had errors - this is probably all your really interested in.

That's about all you need to get up and running with tinderbox. I think I will do one more post covering some housekeeping and other notes. To close off I'll show a script I use to automate running any number of ports inside every build you have configured, I save it in tinderbox/scripts and call it testbuilds.sh

So to make use of the script

and it will go through and compile each port with every tinderbox build you have setup.