(Please read 'How to change from MAKEALL' if you are used to that tool)
+Quick-start
+===========
+
+If you just want to quickly set up buildman so you can build something (for
+example Raspberry Pi 2):
+
+ cd /path/to/u-boot
+ PATH=$PATH:`pwd`/tools/buildman
+ buildman --fetch-arch arm
+ buildman -k rpi_2
+ ls ../current/rpi_2
+ # u-boot.bin is the output image
+
+
What is this?
=============
Caveats
=======
-Buildman is still in its infancy. It is already a very useful tool, but
-expect to find problems and send patches.
-
Buildman can be stopped and restarted, in which case it will continue
where it left off. This should happen cleanly and without side-effects.
If not, it is a bug, for which a patch would be welcome.
Buildman gets so tied up in its work that it can ignore the outside world.
You may need to press Ctrl-C several times to quit it. Also it will print
-out various exceptions when stopped.
+out various exceptions when stopped. You may have to kill it since the
+Ctrl-C handling is somewhat broken.
Theory of Operation
Buildman is a builder. It is not make, although it runs make. It does not
produce any useful output on the terminal while building, except for
progress information (except with -v, see below). All the output (errors,
-warnings and binaries if you are ask for them) is stored in output
+warnings and binaries if you ask for them) is stored in output
directories, which you can look at while the build is progressing, or when
it is finished.
+Buildman is designed to build entire git branches, i.e. muliple commits. It
+can be run repeatedly on the same branch. In this case it will automatically
+rebuild commits which have changed (and remove its old results for that
+commit). It is possible to build a branch for one board, then later build it
+for another board. If you want buildman to re-build a commit it has already
+built (e.g. because of a toolchain update), use the -f flag.
+
Buildman produces a concise summary of which boards succeeded and failed.
It shows which commit introduced which board failure using a simple
red/green colour coding. Full error information can be requested, in which
valid value, and all will be well. Otherwise buildman will perform random
actions. Use -n to check what the random actions might be.
-If you just want to build the current source tree, leave off the -b flag.
-This will display results and errors as they happen. You can still look
-at them later using -s. Note that buildman will assume that the source
-has changed, and will build all specified boards in this case.
+If you just want to build the current source tree, leave off the -b flag
+and add -e. This will display results and errors as they happen. You can
+still look at them later using -se. Note that buildman will assume that the
+source has changed, and will build all specified boards in this case.
Buildman is optimised for building many commits at once, for many boards.
On multi-core machines, Buildman is fast because it uses most of the
* 'freescale & arm sandbox' All Freescale boards with ARM architecture,
plus sandbox
-It is convenient to use the -n option to see whaat will be built based on
-the subset given.
+You can also use -x to specifically exclude some boards. For example:
+
+ buildmand arm -x nvidia,freescale,.*ball$
+
+means to build all arm boards except nvidia, freescale and anything ending
+with 'ball'.
+
+It is convenient to use the -n option to see what will be built based on
+the subset given. Use -v as well to get an actual list of boards.
Buildman does not store intermediate object files. It optionally copies
the binary output into a directory when a build is successful. Size
$ git checkout -b my-branch origin/master
$ # Add some commits to the branch, reading for testing
-2. Create ~/.buildman to tell buildman where to find tool chains. As an
-example:
+2. Create ~/.buildman to tell buildman where to find tool chains (see 'The
+.buildman file' later for details). As an example:
# Buildman settings file
[toolchain-alias]
x86: i386
blackfin: bfin
-sh: sh4
nds32: nds32le
-openrisc: or32
+openrisc: or1k
This selects the available toolchain paths. Add the base directory for
The toolchain-alias section indicates that the i386 toolchain should be used
to build x86 commits.
+Note that you can also specific exactly toolchain prefixes if you like:
+
+[toolchain-prefix]
+arm: /opt/arm-eabi-4.6/bin/arm-eabi-
+
+or even:
+
+[toolchain-prefix]
+arm: /opt/arm-eabi-4.6/bin/arm-eabi-gcc
+
+This tells buildman that you want to use this exact toolchain for the arm
+architecture. This will override any toolchains found by searching using the
+[toolchain] settings.
-2. Check the available toolchains
+Since the toolchain prefix is an explicit request, buildman will report an
+error if a toolchain is not found with that prefix. The current PATH will be
+searched, so it is possible to use:
+
+[toolchain-prefix]
+arm: arm-none-eabi-
+
+and buildman will find arm-none-eabi-gcc in /usr/bin if you have it installed.
+
+[toolchain-wrapper]
+wrapper: ccache
+
+This tells buildman to use a compiler wrapper in front of CROSS_COMPILE. In
+this example, ccache. It doesn't affect the toolchain scan. The wrapper is
+added when CROSS_COMPILE environtal variable is set. The name in this
+section is ignored. If more than one line is provided, only the last one
+is taken.
+
+3. Make sure you have the require Python pre-requisites
+
+Buildman uses multiprocessing, Queue, shutil, StringIO, ConfigParser and
+urllib2. These should normally be available, but if you get an error like
+this then you will need to obtain those modules:
+
+ ImportError: No module named multiprocessing
+
+
+4. Check the available toolchains
Run this check to make sure that you have a toolchain for every architecture.
$ ./tools/buildman/buildman --list-tool-chains
Scanning for tool chains
+ - scanning prefix '/opt/gcc-4.6.3-nolibc/x86_64-linux/bin/x86_64-linux-'
+Tool chain test: OK, arch='x86', priority 1
+ - scanning prefix '/opt/arm-eabi-4.6/bin/arm-eabi-'
+Tool chain test: OK, arch='arm', priority 1
+ - scanning path '/toolchains/gcc-4.9.0-nolibc/i386-linux'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/i386-linux/.'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/i386-linux/bin'
+ - found '/toolchains/gcc-4.9.0-nolibc/i386-linux/bin/i386-linux-gcc'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/i386-linux/usr/bin'
+Tool chain test: OK, arch='i386', priority 4
+ - scanning path '/toolchains/gcc-4.9.0-nolibc/aarch64-linux'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/aarch64-linux/.'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/aarch64-linux/bin'
+ - found '/toolchains/gcc-4.9.0-nolibc/aarch64-linux/bin/aarch64-linux-gcc'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/aarch64-linux/usr/bin'
+Tool chain test: OK, arch='aarch64', priority 4
+ - scanning path '/toolchains/gcc-4.9.0-nolibc/microblaze-linux'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/microblaze-linux/.'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/microblaze-linux/bin'
+ - found '/toolchains/gcc-4.9.0-nolibc/microblaze-linux/bin/microblaze-linux-gcc'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/microblaze-linux/usr/bin'
+Tool chain test: OK, arch='microblaze', priority 4
+ - scanning path '/toolchains/gcc-4.9.0-nolibc/mips64-linux'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/mips64-linux/.'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/mips64-linux/bin'
+ - found '/toolchains/gcc-4.9.0-nolibc/mips64-linux/bin/mips64-linux-gcc'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/mips64-linux/usr/bin'
+Tool chain test: OK, arch='mips64', priority 4
+ - scanning path '/toolchains/gcc-4.9.0-nolibc/sparc64-linux'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/sparc64-linux/.'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/sparc64-linux/bin'
+ - found '/toolchains/gcc-4.9.0-nolibc/sparc64-linux/bin/sparc64-linux-gcc'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/sparc64-linux/usr/bin'
+Tool chain test: OK, arch='sparc64', priority 4
+ - scanning path '/toolchains/gcc-4.9.0-nolibc/arm-unknown-linux-gnueabi'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/arm-unknown-linux-gnueabi/.'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/arm-unknown-linux-gnueabi/bin'
+ - found '/toolchains/gcc-4.9.0-nolibc/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/arm-unknown-linux-gnueabi/usr/bin'
+Tool chain test: OK, arch='arm', priority 3
+Toolchain '/toolchains/gcc-4.9.0-nolibc/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc' at priority 3 will be ignored because another toolchain for arch 'arm' has priority 1
+ - scanning path '/toolchains/gcc-4.9.0-nolibc/sparc-linux'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/sparc-linux/.'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/sparc-linux/bin'
+ - found '/toolchains/gcc-4.9.0-nolibc/sparc-linux/bin/sparc-linux-gcc'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/sparc-linux/usr/bin'
+Tool chain test: OK, arch='sparc', priority 4
+ - scanning path '/toolchains/gcc-4.9.0-nolibc/mips-linux'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/mips-linux/.'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/mips-linux/bin'
+ - found '/toolchains/gcc-4.9.0-nolibc/mips-linux/bin/mips-linux-gcc'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/mips-linux/usr/bin'
+Tool chain test: OK, arch='mips', priority 4
+ - scanning path '/toolchains/gcc-4.9.0-nolibc/x86_64-linux'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/x86_64-linux/.'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/x86_64-linux/bin'
+ - found '/toolchains/gcc-4.9.0-nolibc/x86_64-linux/bin/x86_64-linux-gcc'
+ - found '/toolchains/gcc-4.9.0-nolibc/x86_64-linux/bin/x86_64-linux-x86_64-linux-gcc'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/x86_64-linux/usr/bin'
+Tool chain test: OK, arch='x86_64', priority 4
+Tool chain test: OK, arch='x86_64', priority 4
+Toolchain '/toolchains/gcc-4.9.0-nolibc/x86_64-linux/bin/x86_64-linux-x86_64-linux-gcc' at priority 4 will be ignored because another toolchain for arch 'x86_64' has priority 4
+ - scanning path '/toolchains/gcc-4.9.0-nolibc/m68k-linux'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/m68k-linux/.'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/m68k-linux/bin'
+ - found '/toolchains/gcc-4.9.0-nolibc/m68k-linux/bin/m68k-linux-gcc'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/m68k-linux/usr/bin'
+Tool chain test: OK, arch='m68k', priority 4
+ - scanning path '/toolchains/gcc-4.9.0-nolibc/powerpc-linux'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/powerpc-linux/.'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/powerpc-linux/bin'
+ - found '/toolchains/gcc-4.9.0-nolibc/powerpc-linux/bin/powerpc-linux-gcc'
+ - looking in '/toolchains/gcc-4.9.0-nolibc/powerpc-linux/usr/bin'
+Tool chain test: OK, arch='powerpc', priority 4
+ - scanning path '/toolchains/gcc-4.6.3-nolibc/bfin-uclinux'
+ - looking in '/toolchains/gcc-4.6.3-nolibc/bfin-uclinux/.'
+ - looking in '/toolchains/gcc-4.6.3-nolibc/bfin-uclinux/bin'
+ - found '/toolchains/gcc-4.6.3-nolibc/bfin-uclinux/bin/bfin-uclinux-gcc'
+ - looking in '/toolchains/gcc-4.6.3-nolibc/bfin-uclinux/usr/bin'
+Tool chain test: OK, arch='bfin', priority 6
+ - scanning path '/toolchains/gcc-4.6.3-nolibc/sparc-linux'
+ - looking in '/toolchains/gcc-4.6.3-nolibc/sparc-linux/.'
+ - looking in '/toolchains/gcc-4.6.3-nolibc/sparc-linux/bin'
+ - found '/toolchains/gcc-4.6.3-nolibc/sparc-linux/bin/sparc-linux-gcc'
+ - looking in '/toolchains/gcc-4.6.3-nolibc/sparc-linux/usr/bin'
+Tool chain test: OK, arch='sparc', priority 4
+Toolchain '/toolchains/gcc-4.6.3-nolibc/sparc-linux/bin/sparc-linux-gcc' at priority 4 will be ignored because another toolchain for arch 'sparc' has priority 4
+ - scanning path '/toolchains/gcc-4.6.3-nolibc/mips-linux'
+ - looking in '/toolchains/gcc-4.6.3-nolibc/mips-linux/.'
+ - looking in '/toolchains/gcc-4.6.3-nolibc/mips-linux/bin'
+ - found '/toolchains/gcc-4.6.3-nolibc/mips-linux/bin/mips-linux-gcc'
+ - looking in '/toolchains/gcc-4.6.3-nolibc/mips-linux/usr/bin'
+Tool chain test: OK, arch='mips', priority 4
+Toolchain '/toolchains/gcc-4.6.3-nolibc/mips-linux/bin/mips-linux-gcc' at priority 4 will be ignored because another toolchain for arch 'mips' has priority 4
+ - scanning path '/toolchains/gcc-4.6.3-nolibc/m68k-linux'
+ - looking in '/toolchains/gcc-4.6.3-nolibc/m68k-linux/.'
+ - looking in '/toolchains/gcc-4.6.3-nolibc/m68k-linux/bin'
+ - found '/toolchains/gcc-4.6.3-nolibc/m68k-linux/bin/m68k-linux-gcc'
+ - looking in '/toolchains/gcc-4.6.3-nolibc/m68k-linux/usr/bin'
+Tool chain test: OK, arch='m68k', priority 4
+Toolchain '/toolchains/gcc-4.6.3-nolibc/m68k-linux/bin/m68k-linux-gcc' at priority 4 will be ignored because another toolchain for arch 'm68k' has priority 4
+ - scanning path '/toolchains/gcc-4.6.3-nolibc/powerpc-linux'
+ - looking in '/toolchains/gcc-4.6.3-nolibc/powerpc-linux/.'
+ - looking in '/toolchains/gcc-4.6.3-nolibc/powerpc-linux/bin'
+ - found '/toolchains/gcc-4.6.3-nolibc/powerpc-linux/bin/powerpc-linux-gcc'
+ - looking in '/toolchains/gcc-4.6.3-nolibc/powerpc-linux/usr/bin'
+Tool chain test: OK, arch='powerpc', priority 4
+Tool chain test: OK, arch='or32', priority 4
- scanning path '/'
- looking in '/.'
- looking in '/bin'
- looking in '/usr/bin'
- - found '/usr/bin/gcc'
-Tool chain test: OK
+ - found '/usr/bin/i586-mingw32msvc-gcc'
- found '/usr/bin/c89-gcc'
-Tool chain test: OK
- - found '/usr/bin/c99-gcc'
-Tool chain test: OK
- found '/usr/bin/x86_64-linux-gnu-gcc'
-Tool chain test: OK
- - scanning path '/toolchains/powerpc-linux'
- - looking in '/toolchains/powerpc-linux/.'
- - looking in '/toolchains/powerpc-linux/bin'
- - found '/toolchains/powerpc-linux/bin/powerpc-linux-gcc'
-Tool chain test: OK
- - looking in '/toolchains/powerpc-linux/usr/bin'
- - scanning path '/toolchains/nds32le-linux-glibc-v1f'
- - looking in '/toolchains/nds32le-linux-glibc-v1f/.'
- - looking in '/toolchains/nds32le-linux-glibc-v1f/bin'
- - found '/toolchains/nds32le-linux-glibc-v1f/bin/nds32le-linux-gcc'
-Tool chain test: OK
- - looking in '/toolchains/nds32le-linux-glibc-v1f/usr/bin'
- - scanning path '/toolchains/nios2'
- - looking in '/toolchains/nios2/.'
- - looking in '/toolchains/nios2/bin'
- - found '/toolchains/nios2/bin/nios2-linux-gcc'
-Tool chain test: OK
- - found '/toolchains/nios2/bin/nios2-linux-uclibc-gcc'
-Tool chain test: OK
- - looking in '/toolchains/nios2/usr/bin'
- - found '/toolchains/nios2/usr/bin/nios2-linux-gcc'
-Tool chain test: OK
- - found '/toolchains/nios2/usr/bin/nios2-linux-uclibc-gcc'
-Tool chain test: OK
- - scanning path '/toolchains/microblaze-unknown-linux-gnu'
- - looking in '/toolchains/microblaze-unknown-linux-gnu/.'
- - looking in '/toolchains/microblaze-unknown-linux-gnu/bin'
- - found '/toolchains/microblaze-unknown-linux-gnu/bin/microblaze-unknown-linux-gnu-gcc'
-Tool chain test: OK
- - found '/toolchains/microblaze-unknown-linux-gnu/bin/mb-linux-gcc'
-Tool chain test: OK
- - looking in '/toolchains/microblaze-unknown-linux-gnu/usr/bin'
- - scanning path '/toolchains/mips-linux'
- - looking in '/toolchains/mips-linux/.'
- - looking in '/toolchains/mips-linux/bin'
- - found '/toolchains/mips-linux/bin/mips-linux-gcc'
-Tool chain test: OK
- - looking in '/toolchains/mips-linux/usr/bin'
- - scanning path '/toolchains/old'
- - looking in '/toolchains/old/.'
- - looking in '/toolchains/old/bin'
- - looking in '/toolchains/old/usr/bin'
- - scanning path '/toolchains/i386-linux'
- - looking in '/toolchains/i386-linux/.'
- - looking in '/toolchains/i386-linux/bin'
- - found '/toolchains/i386-linux/bin/i386-linux-gcc'
-Tool chain test: OK
- - looking in '/toolchains/i386-linux/usr/bin'
- - scanning path '/toolchains/bfin-uclinux'
- - looking in '/toolchains/bfin-uclinux/.'
- - looking in '/toolchains/bfin-uclinux/bin'
- - found '/toolchains/bfin-uclinux/bin/bfin-uclinux-gcc'
-Tool chain test: OK
- - looking in '/toolchains/bfin-uclinux/usr/bin'
- - scanning path '/toolchains/sparc-elf'
- - looking in '/toolchains/sparc-elf/.'
- - looking in '/toolchains/sparc-elf/bin'
- - found '/toolchains/sparc-elf/bin/sparc-elf-gcc'
-Tool chain test: OK
- - looking in '/toolchains/sparc-elf/usr/bin'
- - scanning path '/toolchains/arm-2010q1'
- - looking in '/toolchains/arm-2010q1/.'
- - looking in '/toolchains/arm-2010q1/bin'
- - found '/toolchains/arm-2010q1/bin/arm-none-linux-gnueabi-gcc'
-Tool chain test: OK
- - looking in '/toolchains/arm-2010q1/usr/bin'
- - scanning path '/toolchains/from'
- - looking in '/toolchains/from/.'
- - looking in '/toolchains/from/bin'
- - looking in '/toolchains/from/usr/bin'
- - scanning path '/toolchains/sh4-gentoo-linux-gnu'
- - looking in '/toolchains/sh4-gentoo-linux-gnu/.'
- - looking in '/toolchains/sh4-gentoo-linux-gnu/bin'
- - found '/toolchains/sh4-gentoo-linux-gnu/bin/sh4-gentoo-linux-gnu-gcc'
-Tool chain test: OK
- - looking in '/toolchains/sh4-gentoo-linux-gnu/usr/bin'
- - scanning path '/toolchains/avr32-linux'
- - looking in '/toolchains/avr32-linux/.'
- - looking in '/toolchains/avr32-linux/bin'
- - found '/toolchains/avr32-linux/bin/avr32-gcc'
-Tool chain test: OK
- - looking in '/toolchains/avr32-linux/usr/bin'
- - scanning path '/toolchains/m68k-linux'
- - looking in '/toolchains/m68k-linux/.'
- - looking in '/toolchains/m68k-linux/bin'
- - found '/toolchains/m68k-linux/bin/m68k-linux-gcc'
-Tool chain test: OK
- - looking in '/toolchains/m68k-linux/usr/bin'
-List of available toolchains (17):
-arm : /toolchains/arm-2010q1/bin/arm-none-linux-gnueabi-gcc
-avr32 : /toolchains/avr32-linux/bin/avr32-gcc
-bfin : /toolchains/bfin-uclinux/bin/bfin-uclinux-gcc
+ - found '/usr/bin/gcc'
+ - found '/usr/bin/c99-gcc'
+ - found '/usr/bin/arm-linux-gnueabi-gcc'
+ - found '/usr/bin/aarch64-linux-gnu-gcc'
+ - found '/usr/bin/winegcc'
+ - found '/usr/bin/arm-linux-gnueabihf-gcc'
+Tool chain test: OK, arch='i586', priority 11
+Tool chain test: OK, arch='c89', priority 11
+Tool chain test: OK, arch='x86_64', priority 4
+Toolchain '/usr/bin/x86_64-linux-gnu-gcc' at priority 4 will be ignored because another toolchain for arch 'x86_64' has priority 4
+Tool chain test: OK, arch='sandbox', priority 11
+Tool chain test: OK, arch='c99', priority 11
+Tool chain test: OK, arch='arm', priority 4
+Toolchain '/usr/bin/arm-linux-gnueabi-gcc' at priority 4 will be ignored because another toolchain for arch 'arm' has priority 1
+Tool chain test: OK, arch='aarch64', priority 4
+Toolchain '/usr/bin/aarch64-linux-gnu-gcc' at priority 4 will be ignored because another toolchain for arch 'aarch64' has priority 4
+Tool chain test: OK, arch='sandbox', priority 11
+Toolchain '/usr/bin/winegcc' at priority 11 will be ignored because another toolchain for arch 'sandbox' has priority 11
+Tool chain test: OK, arch='arm', priority 4
+Toolchain '/usr/bin/arm-linux-gnueabihf-gcc' at priority 4 will be ignored because another toolchain for arch 'arm' has priority 1
+List of available toolchains (34):
+aarch64 : /toolchains/gcc-4.9.0-nolibc/aarch64-linux/bin/aarch64-linux-gcc
+alpha : /toolchains/gcc-4.9.0-nolibc/alpha-linux/bin/alpha-linux-gcc
+am33_2.0 : /toolchains/gcc-4.9.0-nolibc/am33_2.0-linux/bin/am33_2.0-linux-gcc
+arm : /opt/arm-eabi-4.6/bin/arm-eabi-gcc
+bfin : /toolchains/gcc-4.6.3-nolibc/bfin-uclinux/bin/bfin-uclinux-gcc
c89 : /usr/bin/c89-gcc
c99 : /usr/bin/c99-gcc
-i386 : /toolchains/i386-linux/bin/i386-linux-gcc
-m68k : /toolchains/m68k-linux/bin/m68k-linux-gcc
-mb : /toolchains/microblaze-unknown-linux-gnu/bin/mb-linux-gcc
-microblaze: /toolchains/microblaze-unknown-linux-gnu/bin/microblaze-unknown-linux-gnu-gcc
-mips : /toolchains/mips-linux/bin/mips-linux-gcc
-nds32le : /toolchains/nds32le-linux-glibc-v1f/bin/nds32le-linux-gcc
-nios2 : /toolchains/nios2/bin/nios2-linux-gcc
-powerpc : /toolchains/powerpc-linux/bin/powerpc-linux-gcc
+frv : /toolchains/gcc-4.9.0-nolibc/frv-linux/bin/frv-linux-gcc
+h8300 : /toolchains/gcc-4.9.0-nolibc/h8300-elf/bin/h8300-elf-gcc
+hppa : /toolchains/gcc-4.9.0-nolibc/hppa-linux/bin/hppa-linux-gcc
+hppa64 : /toolchains/gcc-4.9.0-nolibc/hppa64-linux/bin/hppa64-linux-gcc
+i386 : /toolchains/gcc-4.9.0-nolibc/i386-linux/bin/i386-linux-gcc
+i586 : /usr/bin/i586-mingw32msvc-gcc
+ia64 : /toolchains/gcc-4.9.0-nolibc/ia64-linux/bin/ia64-linux-gcc
+m32r : /toolchains/gcc-4.9.0-nolibc/m32r-linux/bin/m32r-linux-gcc
+m68k : /toolchains/gcc-4.9.0-nolibc/m68k-linux/bin/m68k-linux-gcc
+microblaze: /toolchains/gcc-4.9.0-nolibc/microblaze-linux/bin/microblaze-linux-gcc
+mips : /toolchains/gcc-4.9.0-nolibc/mips-linux/bin/mips-linux-gcc
+mips64 : /toolchains/gcc-4.9.0-nolibc/mips64-linux/bin/mips64-linux-gcc
+or32 : /toolchains/gcc-4.5.1-nolibc/or32-linux/bin/or32-linux-gcc
+powerpc : /toolchains/gcc-4.9.0-nolibc/powerpc-linux/bin/powerpc-linux-gcc
+powerpc64 : /toolchains/gcc-4.9.0-nolibc/powerpc64-linux/bin/powerpc64-linux-gcc
+ppc64le : /toolchains/gcc-4.9.0-nolibc/ppc64le-linux/bin/ppc64le-linux-gcc
+s390x : /toolchains/gcc-4.9.0-nolibc/s390x-linux/bin/s390x-linux-gcc
sandbox : /usr/bin/gcc
-sh4 : /toolchains/sh4-gentoo-linux-gnu/bin/sh4-gentoo-linux-gnu-gcc
-sparc : /toolchains/sparc-elf/bin/sparc-elf-gcc
-x86_64 : /usr/bin/x86_64-linux-gnu-gcc
+sh4 : /toolchains/gcc-4.6.3-nolibc/sh4-linux/bin/sh4-linux-gcc
+sparc : /toolchains/gcc-4.9.0-nolibc/sparc-linux/bin/sparc-linux-gcc
+sparc64 : /toolchains/gcc-4.9.0-nolibc/sparc64-linux/bin/sparc64-linux-gcc
+tilegx : /toolchains/gcc-4.6.2-nolibc/tilegx-linux/bin/tilegx-linux-gcc
+x86 : /opt/gcc-4.6.3-nolibc/x86_64-linux/bin/x86_64-linux-gcc
+x86_64 : /toolchains/gcc-4.9.0-nolibc/x86_64-linux/bin/x86_64-linux-gcc
You can see that everything is covered, even some strange ones that won't
be used (c88 and c99). This is a feature.
+5. Install new toolchains if needed
+
+You can download toolchains and update the [toolchain] section of the
+settings file to find them.
+
+To make this easier, buildman can automatically download and install
+toolchains from kernel.org. First list the available architectures:
+
+$ ./tools/buildman/buildman --fetch-arch list
+Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/
+Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.2/
+Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.5.1/
+Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.2.4/
+Available architectures: alpha am33_2.0 arm bfin cris crisv32 frv h8300
+hppa hppa64 i386 ia64 m32r m68k mips mips64 or32 powerpc powerpc64 s390x sh4
+sparc sparc64 tilegx x86_64 xtensa
+
+Then pick one and download it:
+
+$ ./tools/buildman/buildman --fetch-arch or32
+Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/
+Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.2/
+Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.5.1/
+Downloading: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.5.1//x86_64-gcc-4.5.1-nolibc_or32-linux.tar.xz
+Unpacking to: /home/sjg/.buildman-toolchains
+Testing
+ - looking in '/home/sjg/.buildman-toolchains/gcc-4.5.1-nolibc/or32-linux/.'
+ - looking in '/home/sjg/.buildman-toolchains/gcc-4.5.1-nolibc/or32-linux/bin'
+ - found '/home/sjg/.buildman-toolchains/gcc-4.5.1-nolibc/or32-linux/bin/or32-linux-gcc'
+Tool chain test: OK
+
+Or download them all from kernel.org and move them to /toolchains directory,
+
+$ ./tools/buildman/buildman --fetch-arch all
+$ sudo mkdir -p /toolchains
+$ sudo mv ~/.buildman-toolchains/*/* /toolchains/
+
+For those not available from kernel.org, download from the following links.
+
+arc: https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/
+ download/arc-2016.09-release/arc_gnu_2016.09_prebuilt_uclibc_le_archs_linux_install.tar.gz
+blackfin: http://sourceforge.net/projects/adi-toolchain/files/
+ blackfin-toolchain-elf-gcc-4.5-2014R1_45-RC2.x86_64.tar.bz2
+nds32: http://osdk.andestech.com/packages/
+ nds32le-linux-glibc-v1.tgz
+nios2: http://sourcery.mentor.com/public/gnu_toolchain/nios2-linux-gnu/
+ sourceryg++-2015.11-27-nios2-linux-gnu-i686-pc-linux-gnu.tar.bz2
+sh: http://sourcery.mentor.com/public/gnu_toolchain/sh-linux-gnu/
+ renesas-4.4-200-sh-linux-gnu-i686-pc-linux-gnu.tar.bz2
+
+Note openrisc kernel.org toolchain is out of date. Download the latest one from
+http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Prebuilt_versions - eg:
+ftp://ocuser:ocuser@openrisc.opencores.org/toolchain/gcc-or1k-elf-4.8.1-x86.tar.bz2.
+
+Buildman should now be set up to use your new toolchain.
+
+At the time of writing, U-Boot has these architectures:
+
+ arc, arm, blackfin, m68k, microblaze, mips, nds32, nios2, openrisc
+ powerpc, sandbox, sh, sparc, x86
+
+Of these, only arc and nds32 are not available at kernel.org..
+
+
How to run it
=============
$ ./tools/buildman/buildman -b <branch> -n
If it can't detect the upstream branch, try checking out the branch, and
-doing something like 'git branch --set-upstream <branch> upstream/master'
-or something similar.
+doing something like 'git branch --set-upstream-to upstream/master'
+or something similar. Buildman will try to guess a suitable upstream branch
+if it can't find one (you will see a message like" Guessing upstream as ...).
As an example:
This means that it is building 19062 board/commit combinations. So far it
has managed to successfully build 528. Another 36 have built with warnings,
and 124 more didn't build at all. Buildman expects to complete the process
-in an hour and 15 minutes. Use this time to buy a faster computer.
+in around an hour and a quarter. Use this time to buy a faster computer.
To find out how the build went, ask for a summary with -s. You can do this
-either before the build completes (presumably in another terminal) or or
+either before the build completes (presumably in another terminal) or
afterwards. Let's work through an example of how this is used:
$ ./tools/buildman/buildman -b lcd9b -s
see which ones). But still we can see a few failures. The galaxy5200_LOWBOOT
never builds correctly. This could be a problem with our toolchain, or it
could be a bug in the upstream. The good news is that we probably don't need
-to blame our commits. The bad news is it isn't tested on that board.
+to blame our commits. The bad news is that our commits are not tested on that
+board.
Commit 12 broke lubbock. That's what the '+ lubbock' means. The failure
is never fixed by a later commit, or you would see lubbock again, in green,
should be enough to work out what that commit is doing to break these
boards. (In this case pxa did not have cache operations defined).
-If you see error lines marked with - that means that the errors were fixed
+If you see error lines marked with '-', that means that the errors were fixed
by that commit. Sometimes commits can be in the wrong order, so that a
breakage is introduced for a few commits and fixed by later commits. This
shows up clearly with buildman. You can then reorder the commits and try
again.
-At commit 16, the error moves - you can see that the old error at line 120
+At commit 16, the error moves: you can see that the old error at line 120
is fixed, but there is a new one at line 126. This is probably only because
-we added some code and moved the broken line father down the file.
+we added some code and moved the broken line further down the file.
If many boards have the same error, then -e will display the error only
-once. This makes the output as concise as possible.
+once. This makes the output as concise as possible. To see which boards have
+each error, use -l. So it is safe to omit the board name - you will not get
+lots of repeated output for every board.
+
+Buildman tries to distinguish warnings from errors, and shows warning lines
+separately with a 'w' prefix.
The full build output in this case is available in:
err: Output from stderr, if any. Errors and warnings appear here.
log: Output from stdout. Normally there isn't any since buildman runs
- in silent mode for now.
+ in silent mode. Use -V to force a verbose build (this passes V=1
+ to 'make')
toolchain: Shows information about the toolchain used for the build.
sizes: Shows image size information.
-It is possible to get the build output there also. Use the -k option for
-this. In that case you will also see some output files, like:
+It is possible to get the build binary output there also. Use the -k option
+for this. In that case you will also see some output files, like:
System.map toolchain u-boot u-boot.bin u-boot.map autoconf.mk
(also SPL versions u-boot-spl and u-boot-spl.bin if available)
A key requirement for U-Boot is that you keep code/data size to a minimum.
Where a new feature increases this noticeably it should normally be put
-behind a CONFIG flag so that boards can leave it off and keep the image
+behind a CONFIG flag so that boards can leave it disabled and keep the image
size more or less the same with each new release.
To check the impact of your commits on image size, use -S. For example:
--step 2 will show the image sizes for only every 2nd commit (so it will
compare the image sizes of the 1st, 3rd, 5th... commits). You can also use
--step 0 which will compare only the first and last commits. This is useful
-for an overview of how your entire series affects code size.
+for an overview of how your entire series affects code size. It will build
+only the upstream commit and your final branch commit.
You can also use -d to see a detailed size breakdown for each board. This
list is sorted in order from largest growth to largest reduction.
-It is possible to go a little further with the -B option (--bloat). This
+It is even possible to go a little further with the -B option (--bloat). This
shows where U-Boot has bloated, breaking the size change down to the function
level. Example output is below:
run_list_real 1996 2000 +4
do_nandboot 760 756 -4
do_mem_crc 168 68 -100
- colibri_t20_iris: all -9 rodata -29 text +20
+ colibri_t20 : all -9 rodata -29 text +20
u-boot: add: 1/0, grow: 2/-3 bytes: 140/-112 (28)
function old new delta
hash_command 80 160 +80
...
-This shows that commit 19 has increased text size for arm (although only one
-board was built) and by 96 bytes for powerpc. This increase was offset in both
-cases by reductions in rodata and data/bss.
+This shows that commit 19 has reduced codesize for arm slightly and increased
+it for powerpc. This increase was offset in by reductions in rodata and
+data/bss.
-Shown below the summary lines is the sizes for each board. Below each board
-is the sizes for each function. This information starts with:
+Shown below the summary lines are the sizes for each board. Below each board
+are the sizes for each function. This information starts with:
add - number of functions added / removed
grow - number of functions which grew / shrunk
increases, and vice versa.
-Providing 'make' flags
-======================
+The .buildman file
+==================
+
+The .buildman file provides information about the available toolchains and
+also allows build flags to be passed to 'make'. It consists of several
+sections, with the section name in square brackets. Within each section are
+a set of (tag, value) pairs.
+
+'[toolchain]' section
+
+ This lists the available toolchains. The tag here doesn't matter, but
+ make sure it is unique. The value is the path to the toolchain. Buildman
+ will look in that path for a file ending in 'gcc'. It will then execute
+ it to check that it is a C compiler, passing only the --version flag to
+ it. If the return code is 0, buildman assumes that it is a valid C
+ compiler. It uses the first part of the name as the architecture and
+ strips off the last part when setting the CROSS_COMPILE environment
+ variable (parts are delimited with a hyphen).
+
+ For example powerpc-linux-gcc will be noted as a toolchain for 'powerpc'
+ and CROSS_COMPILE will be set to powerpc-linux- when using it.
+
+'[toolchain-alias]' section
-U-Boot's build system supports a few flags (such as BUILD_TAG) which affect
-the build product. These flags can be specified in the buildman settings
-file. They can also be useful when building U-Boot against other open source
-software.
+ This converts toolchain architecture names to U-Boot names. For example,
+ if an x86 toolchains is called i386-linux-gcc it will not normally be
+ used for architecture 'x86'. Adding 'x86: i386 x86_64' to this section
+ will tell buildman that the i386 and x86_64 toolchains can be used for
+ the x86 architecture.
-[make-flags]
-at91-boards=ENABLE_AT91_TEST=1
-snapper9260=${at91-boards} BUILD_TAG=442
-snapper9g45=${at91-boards} BUILD_TAG=443
+'[make-flags]' section
-This will use 'make ENABLE_AT91_TEST=1 BUILD_TAG=442' for snapper9260
-and 'make ENABLE_AT91_TEST=1 BUILD_TAG=443' for snapper9g45. A special
-variable ${target} is available to access the target name (snapper9260 and
-snapper9g20 in this case). Variables are resolved recursively.
+ U-Boot's build system supports a few flags (such as BUILD_TAG) which
+ affect the build product. These flags can be specified in the buildman
+ settings file. They can also be useful when building U-Boot against other
+ open source software.
-It is expected that any variables added are dealt with in U-Boot's
-config.mk file and documented in the README.
+ [make-flags]
+ at91-boards=ENABLE_AT91_TEST=1
+ snapper9260=${at91-boards} BUILD_TAG=442
+ snapper9g45=${at91-boards} BUILD_TAG=443
+
+ This will use 'make ENABLE_AT91_TEST=1 BUILD_TAG=442' for snapper9260
+ and 'make ENABLE_AT91_TEST=1 BUILD_TAG=443' for snapper9g45. A special
+ variable ${target} is available to access the target name (snapper9260
+ and snapper9g20 in this case). Variables are resolved recursively. Note
+ that variables can only contain the characters A-Z, a-z, 0-9, hyphen (-)
+ and underscore (_).
+
+ It is expected that any variables added are dealt with in U-Boot's
+ config.mk file and documented in the README.
+
+ Note that you can pass ad-hoc options to the build using environment
+ variables, for example:
+
+ SOME_OPTION=1234 ./tools/buildman/buildman my_board
Quick Sanity Check
==================
If you have made changes and want to do a quick sanity check of the
-currently-checked-out source, run buildman without the -b flag. This will
-build the selected boards and display build status and errors as it runs
-(i.e. -v amd -e are enabled automatically).
+currently checked-out source, run buildman without the -b flag. This will
+build the selected boards and display build status as it runs (i.e. -v is
+enabled automatically). Use -e to see errors/warnings as well.
+
+
+Building Ranges
+===============
+
+You can build a range of commits by specifying a range instead of a branch
+when using the -b flag. For example:
+
+ upstream/master..us-buildman
+
+will build commits in us-buildman that are not in upstream/master.
+
+
+Building Faster
+===============
+
+By default, buildman executes 'make mrproper' prior to building the first
+commit for each board. This causes everything to be built from scratch. If you
+trust the build system's incremental build capabilities, you can pass the -I
+flag to skip the 'make mproper' invocation, which will reduce the amount of
+work 'make' does, and hence speed up the build. This flag will speed up any
+buildman invocation, since it reduces the amount of work done on any build.
+
+One possible application of buildman is as part of a continual edit, build,
+edit, build, ... cycle; repeatedly applying buildman to the same change or
+series of changes while making small incremental modifications to the source
+each time. This provides quick feedback regarding the correctness of recent
+modifications. In this scenario, buildman's default choice of build directory
+causes more build work to be performed than strictly necessary.
+
+By default, each buildman thread uses a single directory for all builds. When a
+thread builds multiple boards, the configuration built in this directory will
+cycle through various different configurations, one per board built by the
+thread. Variations in the configuration will force a rebuild of affected source
+files when a thread switches between boards. Ideally, such buildman-induced
+rebuilds would not happen, thus allowing the build to operate as efficiently as
+the build system and source changes allow. buildman's -P flag may be used to
+enable this; -P causes each board to be built in a separate (board-specific)
+directory, thus avoiding any buildman-induced configuration changes in any
+build directory.
+
+U-Boot's build system embeds information such as a build timestamp into the
+final binary. This information varies each time U-Boot is built. This causes
+various files to be rebuilt even if no source changes are made, which in turn
+requires that the final U-Boot binary be re-linked. This unnecessary work can
+be avoided by turning off the timestamp feature. This can be achieved by
+setting the SOURCE_DATE_EPOCH environment variable to 0.
+
+Combining all of these options together yields the command-line shown below.
+This will provide the quickest possible feedback regarding the current content
+of the source tree, thus allowing rapid tested evolution of the code.
+
+ SOURCE_DATE_EPOCH=0 ./tools/buildman/buildman -I -P tegra
+
+
+Checking configuration
+======================
+
+A common requirement when converting CONFIG options to Kconfig is to check
+that the effective configuration has not changed due to the conversion.
+Buildman supports this with the -K option, used after a build. This shows
+differences in effective configuration between one commit and the next.
+
+For example:
+
+ $ buildman -b kc4 -sK
+ ...
+ 43: Convert CONFIG_SPL_USBETH_SUPPORT to Kconfig
+ arm:
+ + u-boot.cfg: CONFIG_SPL_ENV_SUPPORT=1 CONFIG_SPL_NET_SUPPORT=1
+ + u-boot-spl.cfg: CONFIG_SPL_MMC_SUPPORT=1 CONFIG_SPL_NAND_SUPPORT=1
+ + all: CONFIG_SPL_ENV_SUPPORT=1 CONFIG_SPL_MMC_SUPPORT=1 CONFIG_SPL_NAND_SUPPORT=1 CONFIG_SPL_NET_SUPPORT=1
+ am335x_evm_usbspl :
+ + u-boot.cfg: CONFIG_SPL_ENV_SUPPORT=1 CONFIG_SPL_NET_SUPPORT=1
+ + u-boot-spl.cfg: CONFIG_SPL_MMC_SUPPORT=1 CONFIG_SPL_NAND_SUPPORT=1
+ + all: CONFIG_SPL_ENV_SUPPORT=1 CONFIG_SPL_MMC_SUPPORT=1 CONFIG_SPL_NAND_SUPPORT=1 CONFIG_SPL_NET_SUPPORT=1
+ 44: Convert CONFIG_SPL_USB_HOST_SUPPORT to Kconfig
+ ...
+
+This shows that commit 44 enabled three new options for the board
+am335x_evm_usbspl which were not enabled in commit 43. There is also a
+summary for 'arm' showing all the changes detected for that architecture.
+In this case there is only one board with changes, so 'arm' output is the
+same as 'am335x_evm_usbspl'/
+
+The -K option uses the u-boot.cfg, spl/u-boot-spl.cfg and tpl/u-boot-tpl.cfg
+files which are produced by a build. If all you want is to check the
+configuration you can in fact avoid doing a full build, using -D. This tells
+buildman to configuration U-Boot and create the .cfg files, but not actually
+build the source. This is 5-10 times faster than doing a full build.
+
+By default buildman considers the follow two configuration methods
+equivalent:
+
+ #define CONFIG_SOME_OPTION
+
+ CONFIG_SOME_OPTION=y
+
+The former would appear in a header filer and the latter in a defconfig
+file. The achieve this, buildman considers 'y' to be '1' in configuration
+variables. This avoids lots of useless output when converting a CONFIG
+option to Kconfig. To disable this behaviour, use --squash-config-y.
Other options
Buildman has various other command line options. Try --help to see them.
+When doing builds, Buildman's return code will reflect the overall result:
+
+ 0 (success) No errors or warnings found
+ 128 Errors found
+ 129 Warnings found
+
How to change from MAKEALL
==========================
to see the results of the build. Rather than showing you all the output,
buildman just shows a summary, with red indicating that a commit introduced
an error and green indicating that a commit fixed an error. Use the -e
-flag to see the full errors.
+flag to see the full errors and -l to see which boards caused which errors.
If you really want to see build results as they happen, use -v when doing a
-build (and -e if you want to see errors as well).
+build (and -e to see the errors/warnings too).
You don't need to stick around on that branch while buildman is running. It
checks out its own copy of the source code, so you can change branches,
This has mostly be written in my spare time as a response to my difficulties
in testing large series of patches. Apart from tidying up there is quite a
-bit of scope for improvement. Things like better error diffs, easier access
-to log files, error display while building. Also it would be nice it buildman
-could 'hunt' for problems, perhaps by building a few boards for each arch,
-or checking commits for changed files and building only boards which use
-those files.
+bit of scope for improvement. Things like better error diffs and easier
+access to log files. Also it would be nice if buildman could 'hunt' for
+problems, perhaps by building a few boards for each arch, or checking
+commits for changed files and building only boards which use those files.
+A specific problem to fix is that Ctrl-C does not exit buildman cleanly when
+multiple builder threads are active.
Credits
=======
projects / people / ms / u-boot.git / blobdiff