[mooming]

Why

.project.config's only definition knob was precompileDefinitions, which becomes an add_compile_definitions and therefore belongs to every configuration. The single per-configuration macro the template carried was a hardcoded -D__DEBUG__ on the Debug flag line — and the Dev line read ${CMAKE_CXX_FLAGS_DEBUG}, so Dev received that define (and anything else written there) as a side effect of CMake's variable semantics rather than by any decision. A host project that needs a definition in one configuration had no input file for it: its only route was -DCMAKE_CXX_FLAGS on the configure command line, which a plain cmake -B build silently drops.

Neither of the tool's existing input files can express it:

Input	Why it cannot carry a per-configuration definition
.module.config's precompileDefinitions	emitted as add_compile_definitions, so it covers every configuration
customCMake.txt, project root	appended after add_subdirectory, so children were already generated without it — measured: a postlude add_compile_definitions reaches the directory's own targets and no child
customCMake.txt, one module	reaches that module's sources only, so a macro that gates code in several modules leaves the executable unable to link

What

One macro per configuration, each on its own flag line:

Configuration	Macro	Line	Flags
Debug	DEBUG_BUILD=1	CMAKE_CXX_FLAGS_DEBUG	-g -O0
Dev	DEV_BUILD=1	CMAKE_CXX_FLAGS_DEV	-g -O1
Release	RELEASE_BUILD=1	CMAKE_CXX_FLAGS_RELEASE	-O3

Each line reads only the variable it assigns, so definitions no longer travel between configurations. Dev's effective flags are unchanged: reading the Debug line produced -g -O0 followed by -O1, and the later -O wins, so the result is spelled out rather than derived.

Source can now ask which configuration it is in (#if DEV_BUILD) and, just as usefully, whether it is the shipping build (#if !RELEASE_BUILD = Debug and Dev). That pair is exactly the set the old __DEBUG__ covered, which is what made the host project's rename a pure rename.

precompileDefinitionsDebug, precompileDefinitionsDev, precompileDefinitionsRelease append -D tokens to those same three lines, for definitions that are not about the configuration itself — a project compiling its test bodies into Debug and Dev writes the same value into the first two keys and leaves the third empty. Values are bare names (BUILD_TESTS BUILD_TESTS style: __TEST__ __UNIT_TEST__), the -D is the emitter's, matching precompileDefinitions. Plain precompileDefinitions keeps meaning "all three configurations".

BuildConfig::GetValues is a passthrough to ConfigParser::GetValues, which already split on space, comma, semicolon and colon; AddConfigDefinitions joins the AddOptimizeLevel emitters in the anonymous namespace. The code carries no explanatory comments — README.md gained two sections ("Configuration macros", "Per-configuration definitions") and --help lists the keys.

Verification

Check	Result
Host project (HardBopEngine) with all three keys configured	grep -c 'DDEBUG_BUILD' → 151 lines in impl-Debug.ninja only; DDEV_BUILD → 151 in impl-Dev.ninja only; DRELEASE_BUILD → 151 in impl-Release.ninja only
__TEST__ via the Debug/Dev keys	151 Debug, 151 Dev, 0 Release
Renaming the host project's 53 __DEBUG__ sites to #if !RELEASE_BUILD	Debug, Dev and Release all build; its EngineTest runs 375 testlets in Debug and Dev and reports the same single pre-existing failure before and after the rename
./generate_cmake_files.sh run twice	second pass changed nothing
clang-format --dry-run -Werror on the four changed sources	clean
makebuild --test-run	3/4 — 03_external_library fails on test_sdk.h not found; reproduced with this change stashed, so pre-existing and unrelated

Co-Authored-By: Claude noreply@anthropic.com

[mooming]

LGTM