Update base image to debian trixie

[aethr]

Updates the base image from debian:bookworm-slim to debian:trixie-slim, fixes the build failure that caused, and cleans up two related issues found along the way.

Three commits, one per independent issue.

1. Keep gfortran-only flags out of the C compiler flags (1f7b57b0)

Independent of the trixie change — this was producing warnings on bookworm too.

Both scripts/ioapi/Makeinclude.* files shared a single MFLAGS between COPTFLAGS and FOPTFLAGS, so the gfortran-only -fbacktrace and -fallow-argument-mismatch were handed to mpicc as well. Every C source file compiled with a pair of:

cc1: warning: command-line option '-fallow-argument-mismatch' is valid for Fortran but not for C

Split the Fortran-only flags into a new FMFLAGS used only by FOPTFLAGS. MFLAGS now holds just the flags both compilers understand.

2. Build on debian trixie (2d6c262b)

The actual failure. Trixie ships GCC 14 (bookworm had GCC 12), which promotes six legacy C diagnostics from warnings to errors by default. The vendored I/O API 3.1 sources are pre-C99 and don't survive that — the build died on:

ioapi/sortic.c:322:30: error: implicit declaration of function 'exit' [-Wimplicit-function-declaration]

The I/O API tarball is fetched from upstream at build time, so patching the sources isn't an option. Instead, COPTFLAGS gains a CLEGACY variable that pins -std=gnu17 and downgrades those six diagnostics back to warnings. Fortran is unaffected.

3. Populate OPENMETHANE_CMAQ_VERSION from a build ARG (5fbf5b17)

The env var was hardcoded to 1.0.0 when introduced (2b2a987e) and nothing bumped it, so published images have been reporting a stale version since 1.0.1.

Follows the approach already used in openmethane/setup-wrf: an ARG defaulting to development, surfaced as an ENV, with CI passing the version read from pyproject.toml. The release workflow tags v$(uv version --short), so prefixing with v reproduces the tag exactly — and tag builds now assert the two agree, which would have caught the original drift.

The ARG sits below the COPY --from=builder lines so a version bump only invalidates the trailing layers rather than the large copies out of the builder stage.

Note: the value's format changes from 1.0.0 to v1.0.2.dev1 (gaining a v prefix), matching setup-wrf. Nothing in this repo consumes the var, but worth checking downstream.

Verification

• Clean docker build --no-cache passes; zero build errors, zero Fortran-flag warnings.
• Full test suite (mcip, icon, bcon) passes on the trixie image.
• Runtime image resolves cleanly on trixie — libnetcdff7, libnetcdf22, libmpich12, csh all present, no missing shared libraries across the built binaries.
• Version plumbing: plain build gives development, --build-arg gives v1.0.2.dev1, OCI label matches, tag check passes on match and fails on mismatch.
• Confirmed the COPY --from=builder layers stay CACHED across a version change.

The warnings that remain in the build log are all upstream's own — Fortran type mismatches (which -fallow-argument-mismatch exists to tolerate) and suffix-rule warnings from the I/O API Makefile.

Out of scope, but noted

Makeinclude.Linux_aarch64gfort uses -march=native -mtune=native, which inside a Docker build compiles for the builder's CPU and can SIGILL on a different host. The arm64 matrix entry is commented out in build_docker.yaml, so it's latent and unverified here. The x86_64 file's -march=core-avx2 has a milder version of the same issue (requires Haswell or newer).

🤖 Generated with Claude Code

[prayner]

There look to be lines in the makeinclude files where -g and -O[2,3] are
set together. In various versions of fortran these aren't compatible
and one will overrule the other. This might be worth checking before
production.

[aethr]

I dug into this with Claude (I lack the expertise with gfortran to diagnose) and it ran some tests which determined -g and -O* are orthoganol on GCC/fortran:

Byte-identical codegen with and without -g, in either order. -g only adds DWARF sections; it never demotes the -O level. This is documented GCC behaviour ("GCC allows you to use -g with -O"), and it holds across the whole GCC family, so scripts/config.cmaq:46-48 and both scripts/ioapi/Makeinclude.Linux_*gfort files are fine as written.

The "last flag wins" rule your colleague is thinking of is real, but it applies to repeated same-family flags (-O0 -O2), and to some non-GCC compilers — older Cray/PGI/SGI ones did silently force -O0 under -g. Neither situation exists in this repo: every affected file is a gfortran/GCC makeinclude, and no line sets two -O levels.

The only cost of keeping -g is binary size and build time, not speed. Given this is an atmospheric model where a production crash is expensive to reproduce, keeping -g for usable backtraces (it pairs with the -fbacktrace already set) is the right call.