Tinderbox extra scripts

Continuing on from my previous two ramblings let's have a look at two scripts I use with my tinderbox setup. It may not be the best place but I decided to keep these within the tinderbox/scripts folder.

The first script is gencompilerenvfiles which I have expanded a little since my previous post.

So the changes since my previous post are fairly small and obvious - first I added NO_WERROR and WERROR which allows some ports to finish building that only generate warnings. Some ports are setup to treat warnings as errors causing the build to stop. While it can make sense with some ports, others it isn't of concern and only gets annoying that the builds stop and you take 10 minutes to figure out that it's all because of a simple warning.

The next change is the addition of ARCH - when building for the same arch as the base system this is of no concern but some ports have a problem building on an amd64 system when the compiler is generating x86 code. The ARCH definition overcomes that issue.

The other change is the conditional addition of CPUTYPE. This is added by calling the script with an argument of cpu. I found a couple of ports that have trouble compiling when targeting the minimum cpu features. While the cpu types used can be adjusted I chose pentium2 as the minimum 32bit as i686 is a common base but sometimes the lack of mmx causes problems, pentium2 is the next one up that has mmx support, pentium4 or prescott are other good choices if you know the minimum cpu your builds need to run on or if you need sse. For amd64 I chose nocona as the first Intel 64bit cpu, not sure that core2 would be any advantage but this can be changed to corei7 to include sse4.2 support. Other options for amd cpu's can be used if you want to test against amd specific features.

The other script I showed previously I called testbuilds.sh. I have expanded this script quite a bit and now call it compileport - while it is now a lot longer than the previous example it's not really more complex. The extra length is from many case and if statements than any real complexity. You can download it below if you want to use it or just read through it.

For the most part you should be able to figure it out based on the comments and help (-h) included within the script. To compile a port we want to know 4 things - sysversion arch compiler and port, sysversion arch and compiler default to current i386/amd64 and gcc/clang and can be left out if you wish to use that combination. That leaves us with specifying the port, giving a minimum of compileport -P <category/portname> to compile against 10-CURRENT.

A few bonus options for sysversion are for preset searches - all current stable and release should be obvious, with releng being a moving target based on system releases. Currently this is set to 9.0 8.3 and 7.4 - being the highest minor release of each major version. Over time this should be updated to include newer releases and drop the less than current releases. So when 9.1 goes beta or RC1 it would be added to the list and after release we can remove 9.0.

If you want to setup default values you can do that through environment variables, which can also be setup in your shell rc files like any other variable. So if you always compile for 9-STABLE you can set OPTBASEVERS to 9-STABLE and it will be used without you having to specify -B 9-STABLE every time. This is where the upper/lower case options come into play. If you have the OPTBASEVERS set to 9-STABLE then compileport -b 8-STABLE will build the port for both 9-STABLE and 8-STABLE but if you use compileport -B 8-STABLE then it will ignore the environment settings and just compile for 8-STABLE. The real advantage to environment settings comes when you want to compile a list of ports. This may be a preset list of all the ports you maintain or you can do something like -

will compile every port you have installed on your system with every tinderbox build you have setup - or -

will compile every port that needs updating against the 9-STABLE builds you have setup. This leads into what I plan to talk about in my next post - using tinderbox to build your own packages.