Version 1.0.1

Added

Header-only components

• New library mode headers in create_component / create_cmake_stages / create_meson_stages
• Templates component_headers.cmake.in and component_headers_dependant.cmake.in
  • INTERFACE library only (no IMPORTED static/shared archives)
  • target_include_directories(... SYSTEM INTERFACE "${BUILDMASTER_INSTALL_INCLUDEDIR}")
  • Depends on <component>_install like library modes
• Install OUTPUT is a stamp file ${builddir}/.buildmaster_headers_installed (avoids empty OUTPUT / CMP0175 with header-only trees)
• install_exec (CMake and Meson) creates missing stamp paths after a successful install
• Simple API:
  • create_cmake_headers_component
  • create_cmake_headers_dependant_component
  • create_meson_headers_component
  • create_meson_headers_dependant_component
• Build stage is kept for a uniform graph (header-only projects are typically no-ops)

Nested linker and binutils propagation

• Nested CMake configures forward the parent toolchain so third-party builds match the top level:
  • Linker: CMAKE_LINKER_TYPE, CMAKE_LINKER, CMAKE_C_COMPILER_LINKER, CMAKE_CXX_COMPILER_LINKER, CMAKE_MT
  • Archiver / nm: CMAKE_AR, CMAKE_C_COMPILER_AR, CMAKE_CXX_COMPILER_AR, CMAKE_RANLIB, CMAKE_C_COMPILER_RANLIB, CMAKE_CXX_COMPILER_RANLIB, CMAKE_NM
  • CMAKE_MODULE_LINKER_FLAGS (in addition to existing EXE/SHARED linker flags)
• tools/cmake/update_toolchain.cmake registers non-empty linker and archiver cache entries for the BuildMaster toolchain dump (paths normalized to forward slashes)
• Nested Meson setups:
  • Build _MESON_LINK_ARGS from CMAKE_EXE_LINKER_FLAGS
  • Linker selection via buildmaster_fuse_ld_flag() (driver-safe -fuse-ld= flavors only):
    • CMAKE_LINKER_TYPE=LLD / forced LLD → -fuse-ld=lld-link (Windows) or -fuse-ld=lld (elsewhere)
    • CMAKE_LINKER_TYPE=MSVC → -fuse-ld=link
    • Else map CMAKE_LINKER / BM_TC_LINKER basename (lld, ld.lld, gold, mold, bfd, …); system ld and absolute paths such as /usr/bin/ld emit no -fuse-ld (GCC rejects path-form -fuse-ld=/usr/bin/ld)
  • Pass AR / RANLIB into Meson setup via cmake -E env (from CMAKE_AR / CMAKE_RANLIB or the process environment)
• Env runners (runner_linux.sh.in / runner_windows.bat.in) export AR, RANLIB, and NM so any command launched through ENV_RUNNER inherits the same binutils as nested CMake/Meson
• env/init_vars.cmake and update_env_runner() resolve AR / RANLIB / NM from CMAKE_AR / CMAKE_RANLIB / CMAKE_NM or ENV{…} before regenerating the runner scripts

Per-component toolchains

• Optional trailing TOOLCHAIN argument on the simple component API (create_cmake_* / create_meson_*, including headers and dependant variants) and on the atomic stage helpers (create_cmake_stages / create_meson_stages); the same profile applies to that component’s configure, build and install whether stages are generated via the factory or wired explicitly
• Named profiles under toolchain/profiles/: gcc, clang, clang-cl, msvc
  • clang: LLD required on Linux; LLD not forced on macOS
  • clang-cl: LLD (lld-link) + llvm-lib (Windows only)
  • msvc: cl + link.exe + lib.exe (Windows only)
  • gcc: system linker/archiver (LLD not forced)
• New module toolchain/ (init, helpers, profiles): validation, platform guards, profile load
• Toolchain file registry (single source of truth for parent and component dumps):
  • buildmaster_toolchain_reset / export / export_raw / write
  • Modules register state in */update_toolchain.cmake; the parent toolchain.cmake is written once at the end of the BuildMaster root CMakeLists.txt
  • buildmaster_toolchain_write_component: parent registry snapshot + profile compiler/binutils CACHE FORCE overlay (no hand-maintained variable list in stage generators)
• buildmaster_clean_ldflags() / buildmaster_clean_cflags() strip known-incoherent tokens by profile:
  • msvc: remove LLD / Clang-LTO switches; other flags preserved
  • clang-cl: remove MSVC LTCG tokens (/GL, /LTCG and variants) that clang-cl ignores or mishandles
• Component-local env runners (normal + silent) when TOOLCHAIN is set; parent global runners are not rewritten
• When TOOLCHAIN is set, configure and build status lines (and dependant configure COMMENT) include (with toolchain <name>); omitted when inheriting the parent job
• IPO/LTO is never enabled by a profile; if the parent already had IPO on, nested stages keep a coherent setting (CMAKE_INTERPROCEDURAL_OPTIMIZATION_* / Meson b_lto) without re-injecting MSVC /GL
• Fully backward compatible: omitting TOOLCHAIN keeps previous behaviour

Fixed

• Per-component TOOLCHAIN and nested BuildMaster installs: components with a toolchain override no longer bootstrap a second install tree under the component build dir (e.g. …/buffer/build/thirdparty/buildmaster/install). Nested configures load a component toolchain file built from the parent registry so BUILDMASTER_INSTALL_*, template dirs (BUILDMASTER_TOOLS_CMAKE_SRCDIR, …) and ENV_* stay unified with the parent; only compilers/binutils are overridden
• Incomplete component toolchain snapshots (missing tool *_SRCDIR / ENV_*) that led to failures such as File /configure.cmake.in does not exist when nested projects created further components
• Nested add_subdirectory(buildmaster) no longer corrupts the shared toolchain.cmake: when BUILDMASTER_CONFIGURED is already TRUE (host loaded the parent dump as CMAKE_TOOLCHAIN_FILE), the root CMakeLists.txt loads helpers, propagates vars, and returns—without toolchain_reset / module re-export / toolchain_write. Previously a nested bootstrap cleared the registry, re-wrote only root-level keys, and overwrote the parent dump, which then broke deeper components with empty template roots (/configure.cmake.in, /component_shared.cmake.in)
• Meson nested setups with system ld: no longer pass -fuse-ld=/usr/bin/ld (or other absolute linker paths) into c_link_args / cpp_link_args. GCC rejects path-form -fuse-ld=; buildmaster_fuse_ld_flag() only emits driver flavor names, so PostgreSQL and other Meson components configure correctly under a default Linux linker
• clang-cl + inherited MSVC LTCG flags: when the parent job uses clang-cl (or a stage selects TOOLCHAIN clang-cl), create_cmake_stages / create_meson_stages strip /GL and /LTCG* from C/CXX and linker flags instead of forwarding them. clang-cl was warning unknown argument ignored for /GL; IPO remains driven by CMAKE_INTERPROCEDURAL_OPTIMIZATION_* and Meson b_lto, not by those MSVC-only switches
• Meson on Windows (MSVC-like toolchains): do not inject /std:c11 into nested Meson c_args. That flag did not fix clang-cl PostgreSQL C99 probes (UCRT complex/tgmath vs Clang _Complex) and could break real cl builds (e.g. Postgres VA_ARGS_NARGS_ / non-constant initializers). Prefer TOOLCHAIN msvc for PostgreSQL on Windows. Upstream projects set their own C standard; only /Z7 is still appended for CodeView on MSVC-like drivers
• Meson stages: SCCACHE_DIR path normalization wrote into CCACHE_DIR instead of SCCACHE_DIR, so sccache cache directories could be lost or overwrite the ccache path during nested Meson setup
• Dependant configure targets (component_*_dependant.cmake.in): under the Ninja generator, long configures (e.g. FFmpeg meson setup) looked hung — the silent env runner swallowed message(STATUS) from the configure -P script. Makefiles still printed progress. Now each dependant configure target sets USES_TERMINAL and a clear COMMENT "Configuring <component>" so Ninja shows the step as soon as it starts
• Dependant configure progress on Windows + Ninja: cmake -E echo "Configuring …" plus the same COMMENT concatenated on one line (Configuring x265Configuring x265). Dropped the redundant echo; a single COMMENT is enough
• Dependant components: indent_level is forced to 0 in create_component when a dependency is set. Hierarchical tabs are only meaningful in the parent configure log (message_indented); dependant stages run at build time and must not inherit plugin-level indentation in status lines or nested stage scripts