release-0.19.0

Adoption and language support

• Forge now adopts and builds C, C++, and mixed-language projects. Recipes and
  named targets can use c_std to select C90, C99, C11, C17, or C23 alongside
  their C++ standard.
• CMake adoption follows considerably more real-world project structure:
  included platform configuration, nested target sources, loop-expanded target
  properties, transitive include directories, public headers and definitions,
  and library-before-consumer superproject ordering. It avoids unavailable
  include paths and no longer lets project headers shadow system headers.
• CMake projects whose selected target links private add_subdirectory()
  libraries now adopt those libraries as named components, choose the primary
  target by default, and retain the complete link closure when building and
  packaging.
• Python3_add_library(... MODULE ... WITH_SOABI) targets are adopted as
  Python extension modules. Forge retains their import name, ABI suffix, and
  package output directory when building and boxing them.
• Runtime-asset inference now recognizes PascalCase C API loaders such as
  LoadTexture and LoadSound.

Building and packaging

• public_defines is available for root and named targets. Forge imports CMake
  PUBLIC and INTERFACE definitions, records them in CBoxes, and applies
  them to downstream consumers.
• Library CBoxes package configured build-header trees as well as public
  headers, including common implementation-header extensions. Dynamic
  libraries no longer require public headers.
• CBoxes also support headerless static components, allowing adopted CMake
  OBJECT library dependencies to build and package as part of their parent
  library's link closure.
• Source dependencies can consume component CBoxes and their embedded CBox
  dependencies, preserving the nested static-library link closure.
• The top-level help banner now displays the installed Forge version.

Reliability and validation

• CBox archive validation is stricter: it validates the complete central
  directory and rejects multi-disk or ZIP64 archives, symbolic links,
  control-character or colon paths, and case-colliding paths before extraction.
• Failed recipe parsing is atomic: invalid sections, keys, or values leave the
  caller's existing recipe unchanged.
• Fixed profile-scoped local and Git source dependencies: a root-only profile
  is no longer forwarded to a dependency that has no matching selector rules.
• Added scripts/validate-showcases.sh, an isolated clean-checkout validation
  suite for Raylib, Meshoptimizer, AssetKit, assetkit-blender, fmt, and spdlog.
  It verifies both runtime assets and CBox/package dependency chains.

Documentation and maintenance

• Expanded the recipe schema and documentation for C projects, Python
  extensions, exported definitions, and the validated showcase chain. Corrected
  the self-hosting source manifest, test labels, and workflow marker so the
  documented commands match current Forge behavior.
• Internal build selection, workspace routing, dependency cache and lockfile
  handling, run-cache metadata, and CBox creation paths were consolidated to
  keep build, box, release, and workspace commands on the same resolution
  model.

release-0.18.1

• Source dependencies now rebuild when switching build configuration, preventing
  a cached Release library from being reused by a Debug consumer (and vice
  versa).
• forge run <project> --config=<configuration> now selects the matching
  cached run variant from a workspace root.

release-0.18.0

• forge adopt now imports CMake cmake -E copy_directory rules as runtime
  assets, including component projects that are normally configured through a
  CMake superproject. Resource trees are staged beside the generated executable.
• CMake adoption now follows active platform and option branches, source globs,
  Objective-C++ sources, selected-target compile settings, and public include
  contracts. Generated builds retain platform link requirements without
  cross-dependency cache collisions.
• Adopted CMake projects recognize common package providers (including GLFW,
  EnTT, glm, yaml-cpp, spdlog, fmt, and nativefiledialog). Interactive macOS
  builds can install missing Homebrew providers and provision a project-local
  vcpkg checkout plus its manifest dependencies, safely resuming interrupted
  installs.
• Recipes can override an adopted system provider with a selected local, Git,
  or Forge package dependency, allowing experiments with neighbouring clones
  without editing generated platform-link settings.
• Compiled dependencies may use an older C++ standard than their consumer,
  while Forge continues to reject consumers that do not meet a dependency's
  required language standard.
• forge run at a workspace root now lists runnable projects and shows the
  exact command to launch one. forge release-git also refuses to tag a bump
  whose release-notes entry still contains only the placeholder text.

release-0.17.4

• CMake adoption resolves simple set(...) and list(APPEND ...) source lists
  for the selected target, respects inactive default option branches, reads
  CMAKE_CXX_STANDARD, and can derive versions from exact
  <PROJECT>_VER_MAJOR, _MINOR, and _PATCH macros. This correctly adopts
  projects such as spdlog without pulling in their tests and benchmarks.
• Dependency suggestions for compiled CMake libraries now follow headers
  reached by their selected sources, avoiding optional public-header adapters
  that are not part of the library's default build.

release-0.17.3

• Added SHOWCASE.md, a verified EnTT-to-cbox-to-EnTT-Pacman walkthrough
  covering cbox consumption, SDL2 provider installation, and a legacy API
  migration needed to run the game.
• CMake adoption now selects the concrete target matching project(...) when
  projects also define auxiliary header-only, C API, example, or test targets.
  It retains only that target's sources and effective unconditional metadata,
  including option-enabled source files.
• Adopted CMake libraries can derive a semantic version from an exact packed
  <PROJECT>_VERSION public-header macro, and known standard/platform headers
  no longer become misleading dependency suggestions.

release-0.17.2

• forge adopt now recognizes CMake find_package(SDL2) declarations and
  emits portable SDL2 system-library requirements with Homebrew and Apt
  provider mappings.
• Interactive macOS builds offer to install missing declared Homebrew provider
  packages, then use their discovered CMake prefixes for headers and libraries.
  Non-interactive and CI builds never prompt or install packages.

release-0.17.1

• Made forge adopt reliably adopt CMake interface libraries that publish
  headers from source roots such as src/, while excluding optional CMake
  subprojects and their unrelated dependencies.
• Added public-header validation entry points. Header-only packages can keep
  their complete installed header tree while validating an aggregate umbrella
  header when individual leaf headers are not standalone entry points.
• Made CMake project-source variables and optional __has_include branches
  resolve without producing false dependency suggestions. Source-root headers
  are packaged beneath the conventional include/ directory in cboxes.

release-0.17.0

• Added release-integrity validation before building or tagging: the current
  release-note section and any configured generated version header must match
  the recipe version and build number.
• forge release and hosted release preparation now write target-qualified
  release manifests containing SHA-256 checksums for every staged artifact,
  plus a checksum for each manifest itself.
• Extended forge release-git --dry-run through local hosted release
  preparation while preserving its no-tag, no-push guarantee.
• Made repeated forge adopt runs safe and non-destructive, and made generated
  workflow-release TODOs name the required cross-target lock update command.

release-0.16.0

• Imported-library packages can now depend on and embed other Forge packages,
  making vendor SDK dependency graphs reproducible.
• Hardened the OpenAL-style platform-adapter workflow: header-only adapters can
  carry target-filtered imported libraries while other hosts retain their
  platform system-library requirements.
• Preserved imported-library release-workflow skipping on hosts without a
  matching import profile, and documented cross-target workflow-release lock
  updates and Windows DLL/import-library packaging coverage.

release-0.15.1

• Added [release].unblock for platform-specific executable unblocking
  instructions. Forge selects the current platform's file and packages it as
  UNBLOCK.txt alongside the automatically included project README.md, while
  preserving the existing [release].readme behavior.
• Added macOS Gatekeeper quarantine and Windows downloaded-file unblocking
  instructions to Forge's own release archives.