Skip to content

Continuous Integration

Jump to bottom
bbuhrow edited this page Jun 9, 2026 · 1 revision

Continuous Integration

YAFU uses GitHub Actions to build the project on every push and to attach a matrix of optimized binaries to each tagged release. This page explains what CI builds, how, and how the same machinery maps to what you build locally.

The CI workflows themselves live in .github/workflows/ in this repo. The build recipes they invoke are exactly the same Makefile.new and build.vc22/ property sheets described in Building YAFU — there's no separate "CI build script" you'd need to learn.

The build matrix

CI builds YAFU across three platform/toolchain legs, each crossed with a set of ISA targets:

Platform Toolchain Build driver Status
Linux x86_64 gcc Makefile.new Active
Windows x86_64 MSYS2 / MinGW-w64 gcc Makefile.new (STATIC_WIN=1) Active — produces the released .exe files
Windows x86_64 MSVC (Visual Studio 2022) build.vc22/ solution + .props files Work in progress for CI; IDE build is functional

For each platform, the ISA matrix is:

Target name Makefile flag(s) CPU floor
generic FORCE_GENERIC=1 (or no ISA flags) Any x86-64 CPU
sse41 USE_SSE41=1 Intel Core 2 / Penryn (2008) and newer
avx2 USE_AVX2=1, USE_BMI2=1 Haswell (2013) and newer
avx512 USE_AVX512=1 Skylake-X, Cascade Lake, Zen 4, etc.
avx512ifma USE_AVX512IFMA=1 Ice Lake and newer

The CI build for each cell of the matrix is functionally:

make -f Makefile.new yafu \
    ECM=1 \
    OMP=1 \
    <ISA flag for this cell> \
    [STATIC_WIN=1 on Windows MinGW]

STATIC_WIN=1 on the Windows MinGW leg produces a fully-static .exe that runs in cmd.exe and PowerShell with no DLL dependencies — see Building-YAFU#msys2--mingw-w64-fully-static-windows-binaries for details.

What you get from a tagged release

On every tagged release (e.g. v3.1.2), CI uploads the full Windows matrix to the release page:

File Best for
yafu-windows-generic.exe Any x86-64 CPU — widest compatibility
yafu-windows-sse41.exe Intel Core 2 / Penryn (2008) and newer
yafu-windows-avx2.exe Haswell (2013) and newer — recommended for most users
yafu-windows-avx512.exe Skylake-X / Cascade Lake / Zen 4 (AVX-512)
yafu-windows-avx512ifma.exe Ice Lake and newer — best ECM performance

All Windows builds are fully static — no extra DLLs, runs in cmd.exe and PowerShell.

Not sure which to pick? Run wmic cpu get name in a Windows command prompt and look up your CPU generation, or just start with avx2 — it works on nearly every CPU sold since 2015.

The latest release is always at https://github.com/bbuhrow/yafu/releases/latest.

Reproducing a CI build locally

Because CI uses the same Makefile.new you would, reproducing any specific release artifact locally is a one-liner once your dependencies are in place. For example, to reproduce yafu-windows-avx2.exe under MSYS2/MinGW-w64:

cp config.mk.example config.mk
# Edit config.mk to enable:
#   ECM := 1
#   OMP := 1
#   USE_AVX2 := 1
#   STATIC_WIN := 1
make -f Makefile.new yafu

On Linux for the equivalent dynamic binary:

make -f Makefile.new yafu ECM=1 OMP=1 USE_AVX2=1

To see exactly what the build resolved to (paths, flags, compiler family), run:

make -f Makefile.new info

This is also what CI runs to log its configuration, so you can compare directly.

The MSVC leg

The Windows MSVC build is configured through three property sheets in build.vc22/:

  • Directory.Build.props — global settings inherited by every project in the solution.
  • build_config.props — toolset selection (e.g. v143, Intel oneAPI) and overall build configuration. CI uses this to swap toolsets across matrix cells.
  • libs_and_extensions.props — dependency paths and the PreprocessorDefinitions line where ISA extensions are enabled per build.

The IDE build (open build.vc22/yafu.sln in Visual Studio 2022, build x64 / Release) works today. Driving the MSVC build from CI is an in-progress effort; expect changes here as it matures.

Why CI matters for users

A few things this CI setup gives you, even if you never touch the workflow files yourself:

  • Pre-built binaries are kept current. The release .exe files are produced by the same commit, with the same flags, every time.
  • You don't need to guess which ISA to pick. The artifact names match the CPU generations directly; pick the one matching your hardware.
  • The build is reproducible. Whatever flags CI uses can be set in your own config.mk to reproduce the exact same binary locally.
  • Pull requests are built across the matrix. When you contribute changes, CI verifies the build works for every platform/ISA combination, which catches portability bugs early.

See also

  • Building YAFU — the underlying build recipes used by CI and by hand
  • Home — table of contents for the rest of the wiki
  • The releases page — download the latest binaries

Clone this wiki locally