Modern build: Docker, vcpkg and CMake, and a build that works on current Boost

[MagnaibayarMN]

Makes QuickFAST buildable again on a machine bought this decade, and turns "get QuickFAST compiling" from a day of archaeology into one command.

docker build -t quickfast .
docker run --rm quickfast -?

That is the whole setup. No MPC, no Boost, no Xerces-C, no environment variables, nothing installed on the host.

The problem this solves

QuickFAST's build instructions have not moved since 2017, and they were already pointing at the past then. setup.sh still defaults to this:

export BOOST_ROOT=~/boost/boost_1_38_0     # Boost 1.38 — February 2009
export BOOST_VERSION=boost-1_38
export XERCES_ROOT=~/xerces/xerces-c-3.0.1 # Xerces-C 3.0.1 — 2008
export XERCES_LIBNAME=xerces-c-3.0

So a newcomer has three ways to go, and until now all three ended badly:

Use the Boost your distribution ships. Every current distribution is on Boost 1.74 or later. The build dies immediately:

/usr/include/boost/asio/io_service.hpp:27:20: error: conflicting declaration
  'typedef class boost::asio::io_context boost::asio::io_service'

followed by a few hundred cascading errors. Nothing in the error text suggests the cause, and the cause is one line in AsioService_fwd.h that forward declares an Asio type Asio itself has redefined.

Build the Boost that setup.sh names. Boost 1.38 is from 2009 and does not compile with a current gcc or clang. Neither does Xerces-C 3.0.1. You are now debugging two dependencies before you have compiled a line of QuickFAST.

Find some Boost in between. There is a narrow window that works — and finding it means bisecting sixteen years of Boost releases, because Asio changed in at least four distinct ways over that span:

Boost	What happens to QuickFAST
below 1.66	builds, if your compiler is old enough to build Boost itself
1.66 – 1.86	io_service became a typedef; QuickFAST's forward declaration conflicts with it
1.87 and later	the io_service name is gone entirely, along with work, resolver::query and from_string
recent releases	Asio's date_time based timers became opt-in, so deadline_timer disappears too

And that is only Boost. Xerces-C moved from 3.0 to 3.2, so the library name setup.sh exports is wrong as well, and MPC itself is a separate tool that has to be fetched and put on $PATH before any of this starts.

The result is that a library which is genuinely useful — a mature, fast, permissively licensed FAST decoder — is effectively unavailable to anyone who is not willing to spend a day on it. That is the barrier this PR removes.

What it does

Seven commits, each self-contained:

1. Build against current Boost releases. The actual source fixes, every one of them selected on BOOST_VERSION so that older Boost builds exactly as it did before. The root cause is the forward declaration described above; the rest follows from it — AsioService now offers the get_executor() that Asio's I/O objects ask for, and a new header, Communication/AsioCompatibility.h, spells make_address, post, restart and executor_work_guard the way the Boost being compiled against expects, so the call sites do not each carry a version test. TCPReceiver uses the results-range form of resolve, and the two burst-sender examples use steady_timer and bind_executor. Verified against Boost 1.83, 1.88 and 1.91.

2. An optional CMake build. find_package locates Boost and Xerces-C instead of a hand-edited script naming absolute paths. Installing exports a target, so a downstream project needs two lines:

find_package(QuickFAST REQUIRED)
target_link_libraries(app PRIVATE QuickFAST::QuickFAST)

3. A vcpkg manifest and CMake presets. This is what makes the build reproducible rather than merely possible. The manifest pins a vcpkg baseline by commit, so cmake --preset vcpkg builds against one exact Boost and one exact Xerces-C — the same ones on your laptop, on CI, and in two years' time. Version drift stops being something you manage and starts being something recorded in a file.

4. A Dockerfile. Multi-stage: vcpkg pinned to that same baseline builds the dependencies, QuickFAST and its tests are built and run, and the example programs land in a 121 MB runtime image. Boost from source is slow, so the vcpkg downloads and built packages live in BuildKit cache mounts — after the first build only QuickFAST itself recompiles.

5. A GitHub Actions workflow. Linux with gcc and clang, macOS, Windows with MSVC, the Docker image, and a small project built against the installed CMake package. One job regenerates the MPC makefiles, so the original build cannot rot unnoticed.

6. A development container. The toolchain, vcpkg and gdb, ready for an editor that understands dev containers.

7. README build instructions. CMake, vcpkg, Docker and MPC, side by side.

What it does not do

The MPC build is untouched. No .mpc, .mpb, .mwc, .features or setup script is modified. Both builds work from the same working copy, and CI checks that the MPC project files still generate. This is an addition, not a migration — anyone with a working MPC setup keeps it.

Verification

Every claim above was built and run, not assumed:

Environment	Boost	Result
Ubuntu 24.04, gcc 13	1.83 (distribution)	library, 6 examples, 112 test cases pass
Ubuntu 25.10, gcc 15	1.88 (distribution)	library, 6 examples, 112 test cases pass
Docker image, vcpkg	1.91 (built from source)	library, 6 examples, 112 test cases pass

Also checked: static and shared library builds, cmake --install followed by a separate consumer project linking QuickFAST::QuickFAST, and docker run --rm quickfast producing InterpretApplication's usage output.

The macOS and Windows CI jobs have not run yet — this PR is the first time they will.

Upstream

The two commits that matter most to everyone else are already proposed to the original project:

• Build against current Boost releases objectcomputing/quickfast#148 — Build against current Boost releases
• Add an optional CMake build objectcomputing/quickfast#149 — Add an optional CMake build

The remaining five are held back deliberately: that repository has not seen a commit since March 2017, and seven simultaneous pull requests would bury a maintainer rather than help one. If those two land, the rest follow.

🤖 Generated with Claude Code

https://claude.ai/code/session_017BnyHwonMsq7k6uQxWpVGF