You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(build): Windows runtime-DLL deployment beside the executable; v0.0.73
A directly-launched Windows .exe cannot RUNPATH-locate a dependency's runtime
DLL (PE has no rpath). mcpp now stages every *.dll found in a linked
dependency's [runtime] library_dirs into bin/, beside the produced executable,
via a ninja copy edge the executable takes as an implicit dependency. This
completes an abstraction already designed but unimplemented on PE: RPATH on
ELF/Mach-O, copy-beside-exe on PE — both 'make the runtime library locatable'.
The deploy is filtered by the *.dll extension, NOT by if constexpr(is_windows)
and with no schema change: a real Linux/macOS dependency ships .so/.dylib
(never .dll), so the glob matches nothing and non-Windows builds are
byte-for-byte unchanged. A recipe declares [runtime] library_dirs globally;
only a Windows prebuilt-DLL package populates the deploy list. This unblocks a
Windows compat.openblas (import-lib + runtime DLL) and any future prebuilt-DLL
package.
Test: tests/e2e/84_runtime_dll_deploy.sh exercises the exact copy path on a
Linux host via a dummy dependency shipping a stub libdummy.dll (asserts the DLL
is staged beside the exe byte-for-byte; a non-DLL sibling is not). The Windows
link/run half is verified in mcpp-index CI (design Phase D). Regression: unit
suite (27 ok), e2e 74/80/81/83, self-host build.
See .agents/docs/2026-06-29-windows-runtime-dll-deployment-and-openblas.md.
0 commit comments