The Amsterdam Compiler Kit: a portable toolchain from 1987 still in use

One toolchain, four languages, fourteen targets

The Amsterdam Compiler Kit is a complete compiler toolchain consisting of front end compilers for a number of different languages, code generators, support libraries, and all the tools necessary to go from source code to executable on any of the platforms it supports. The copyright line in the README dates it to 1987-2005 at the Vrije Universiteit in Amsterdam, with a revision stamp of 2025-04-17, and the version banner reads V6.2+. The languages are ANSI C, Pascal, Modula 2 and Basic, with K&R supported via the ANSI C compiler. The platform list is the striking part: cpm producing i80 CP/M .COM files, em22 bytecode, linux386 for ELF executables on PC Linux, linux68k for m68020, linuxmips for little-endian MIPS32r2, linuxppc for PowerPC, minix68k, msdos386 producing i386 MS-DOS 32-bit DPMI .EXE files, msdos86 for i86 .COM files, osx386 and osxppc for MachO, pc86 for bootable 8086 floppy images, pdpv7 for PDP/11 V7 Unix binaries, and rpi for Raspberry Pi GPU binaries. A single command can target a 1980s CP/M .COM file or a Raspberry Pi binary from the same source tree.

Building it, and the toolchain you need first

The build mechanism has been rewritten twice according to the README, and the requirements list is specific. You need an ANSI C compiler, which defaults to gcc and can be changed with the CC make variable, plus flex and yacc, GNU make, Lua of any version with the lua-posix library installed, Python 3.4 or above, and about 1GB in the target directory. The build works on Unixish systems including Linux, OSX, and Windows using MSYS2 and mingw32. There is one configuration step before anything compiles. You edit the Makefile, where there is a small section at the top for configuration, and the README says the only one you may want to edit is PREFIX, which changes where the ACK installs to, and PLATS, which changes which architectures are built, with the platforms to look at in plat/*. The Makefile in the repository confirms the shape. It sets DEFAULT_PLATFORM to pc86, sets PLATS to all with a commented example of narrowing it to linux386 linuxppc linuxmips, and it refuses a command-line PLATS with an error that says not to set it on the command line, for reasons, and to edit the Makefile instead. PREFIX defaults to /opt/pkg/ack on non-Windows and c:/ack on Windows.

make, then make install

The two commands that get you from a checkout to a working compiler are the oldest in the documentation. The first builds:

    make

The README adds that the make system is fully parallelisable by default but does take a while to start up. The second installs:

    sudo make install

That installs the ACK into your PREFIX directory, which the README says is /usr/local by default, although the Makefile in the repository ships a different default of /opt/pkg/ack on non-Windows systems, and the Makefile also documents leaving PREFIX as the staging install directory if you want to run the ACK from the build directory instead of installing it. After that the README says the ACK should now be ready to use. The install target in the Makefile is a simple pipe that creates the prefix directory and untars the staged tree into it, and the actual build is driven by the included build/ab.mk with progress information disabled.

The ack command, and how it picks a language

The main command to use is ack, which invokes the compiler and the linker. The documented options are short and mostly letter-shaped. -m<platform> builds for the specified platform, -o <file> specifies the output file, -c produces a .o file, -c.s produces a .s assembly file, -O enables optimisation with levels going up to 6, -ansi compiles ANSI C when using the C compiler, and -v is more verbose and repeatable. The language is chosen from the file extension, which is a pleasantly old-fashioned design: .c is C, either ANSI or K&R, .b is the PDP-11 dialect of B, .bas is Basic, .mod is Modula-2, .ocm is Occam 1, .p is Pascal, .o is an object file, .s is assembly, and .e is an ACK intermediate code assembly file. There are known working example programs in the examples directory, and the README gives this sample command line:

ack -mlinux386 -O examples/paranoia.c

The examples directory in the repository confirms the multi-language claim with a single program per language, including hilo.c, hilo.bas, hilo.mod, hilo.ocm, hilo.p, dhrystone-style dhry_1.c and dhry_2.c, mandelbrot.c, paranoia.c and startrek.c.

The gotchas section is the most useful part of the README

The README has a Gotchas section that reads as advice from someone who has been bitten. Look at plat/PLATFORMNAME/README for information about the supported platforms. The library support is fairly limited, and for C it is at roughly the ANSI C level, with the other languages similar. When compiling languages other than C, the ACK will usually look at the first character of the file, and if it is a # then the file will be run through the C preprocessor anyway. BSD systems may need to raise the number of file descriptors, with ulimit -n 200 given as an example, before the ACK will compile. The ACK uses its own .o format, so you will not be able to mix the ACK's object files and another compiler's. And the distribution contains everything, including the weird, ancient, archaic stuff that does not work any more and never will, such as the int EM interpreter and the assembler-linkers, with only some of it building. The pointer for that last one is to look for build.lua files, which is how the build system marks what is live.

What the disclaimer says about using it in 2026

The README closes with a DISCLAIMER that is unusually blunt, and it is the single most important paragraph for anyone deciding whether to adopt this. The ACK is mature, well-tested software, but the environment in which it was developed for and tested under is rather different from that available on today's machines. There will probably be little in the way of logical bugs, but there may be many compilation and API bugs. The author asks users who wish to use the ACK to join the mailing list, because the project is interested in reports of success and particularly failure, and bug fixes are even more welcome. The licence is BSD-like, with the full text in the Copyright file rather than in a file named LICENSE, and the mailing list is at the project web site. The repository reflects the same mixture of living and archived code: directories for lang, lib, mach, plat, modules, util, h, include, fcc, fast and emtest alongside doc, tests, etc, build and bin, plus a Copyright file, CHANGES, NEW, TODO and Action at the top level.

Release history that tells you how it is maintained

The release list is short and revealing. There is a dev tag described as a nightly development build from 2025-12-20, and then release-6-0-pre-5 and release-6-0-pre-4, both from 2016-06-04. The last push to the repository was on 2026-07-18, so work continues on the default branch while the tagged releases remain at the 6.0 pre-release stage. The README banner calls the current version V6.2+, which sits slightly ahead of the newest tag. Reading those two facts together gives the maintenance picture: a project with a long steady trickle of commits and a release process that has not produced a numbered 6.0 package in a decade. The build system in the repository is a Python-driven one, with build.py at the root and a build directory, and there is a .drone.yml and a .travis.yml for continuous integration, alongside .github for GitHub workflows, so the automation exists in two generations. The default branch is called default rather than master, which is unusual for a project of this vintage and suggests the branch layout was modernised at some point.

Editorial conclusion

The Amsterdam Compiler Kit suits a systems programmer who needs a self-contained toolchain for an obscure target, who wants one command to compile and link C, Pascal, Modula 2 or Basic, or who is interested in how a portable compiler kit was put together. It is the wrong tool for a modern project, because the library support sits at roughly the ANSI C level, the object format is its own and cannot be mixed with another compiler's, and the README states plainly that the environment it was developed in differs from today's machines and that there may be many compilation and API bugs. Verify first which of the fourteen platforms you actually need, since the Makefile builds them all by default and the README advises checking plat/PLATFORMNAME/README for the supported ones, and note that the last push was on 2026-07-18 with the newest tagged release still 6.0pre5 from 2016.

Frequently asked questions

Official sources

1. davidgiven/ack on GitHub
2. Issues
3. Project website
4. README
5. Releases