Here's a
docker file which sets up a container with a working CHDK build environment. I wouldn't really recommend setting up docker just to build CHDK, but it may be convenient for people who already use it.
Use cases:
1) You don't want to mess with getting a compatible toolchain, building capstone etc, or having the CHDK toolchains in your normal environment
2) Autobuilds could be deployed on AWS etc and only executed as needed, though you'd want a slightly different container configuration to fetch the source and push the files to s3 or whatever.
Overview:
The container is based on debain stretch, with arm-none-eabi-gcc 5.4.1 and host gcc 6.3 (both from distro packages) and capstone 4.0.2. The intended use is for source code to be mounted from the host using a bind mount, so the container essentially replaces the make command and you still edit, grep, upload binaries to the camera etc from your regular desktop.
usage
Download the Dockerfile into an empty directory and build like
docker build -t chdkbuild .
Running
To build CHDK, you need to mount the source you want to use on /srv/src, and pass whatever make command you'd normally use. On Linux, you probably want the container to run as your normal user as well. Put together, you end up with a command like
docker run --rm --user=$(id -u):$(id -g) -v $HOME/chdk/trunk:/srv/src chdkbuild make PLATFORM=ixus175_elph180 PLATFORMSUB=100c
If your firmware dumps are in a separate tree, you can mount that as well, like
docker run --rm --user=$(id -u):$(id -g) -v $HOME/chdk/trunk:/srv/src -v $HOME/chdk/dumps:/srv/dumps:ro chdkbuild make PRIMARY_ROOT=/srv/dumps PLATFORM=ixus175_elph180 PLATFORMSUB=100c
Notes:
The PRIMARY_ROOT (and any other paths) on the command line must match the path inside the container, not the path on the host system.
--rm isn't strictly required, but you probably don't want docker leaving a stopped container around every time you run.
edit: Alternatively you could give the container a name in the first run, and then reuse it with docker start to execute the exact same command again, like:
docker run --user=$(id -u):$(id -g) -v $HOME/chdk/trunk:/srv/src --name makeg7x chdkbuild make PLATFORM=g7x PLATFORMSUB=100d clean fir
... edit code ...
docker start -a makeg7x
but keeping track of which container to use if you do more than build one command would likely be inconvenient
If you were using this a lot, you'd probably want a wrapper script to pass all the docker options.
You can get a shell in the container by adding -ti and omitting the make command, like
docker run -ti --rm --user=$(id -u):$(id -g) -v $HOME/chdk/trunk:/srv/src chdkbuild
You can then run build commands interactively in the shell.
I've tested it on Linux and windows, and it presumably should work on Mac. On windows, you don't need to set the user.
Performance seems fine. In fact, my windows laptop building in the container is faster than my higher spec desktop building directly in windows.
Caveats:
Tool binaries (capdis etc) will be compiled for container. They may not run on the host although they're statically linked, so they have a decent chance of running on Linux hosts.
If you specify a user on the command line, it will not exist in the container /etc/passwd file, which will show "I have no name!" in the bash prompt. This doesn't interfere with building CHDK, but may break other commands.
The make starts in /srv/src. If you want to build in a subdirectory, you can use -C dir in the make command line, or use -w in docker command line to set the workdir
The container doesn't include svn, so it doesn't add revision numbers to builds. It would be easy to include, but potentially problematic if your host system had a different version of svn.
It's quite large (330MB) of which ~50 is the base Debian system and the rest is related to the toolchains.
Edit:
If you alternate compiling through the container and the native toolchain on windows, you can end up with confusing errors: The container leaves (linux) executables without a .exe suffix. clean on windows only cleans the .exe files, but bash in the windows toolchain can still try to execute the files without .exe. To avoid issues like this, clean from the container.
