Документация Docs/ru/reference/cmake-and-buildtools/pipeline.md

Конвейер BuildTools

Этот документ объясняет поэтапный CMake-конвейер в BuildTools/cmake/. Он дополняет основанное на исходниках руководство Build Workflow: в нём описан пользовательский подход к сборке, а здесь — владение реализацией. Локальные targets и связывание roles описаны в ProjectDependencies.md, точные публичные CMake declarations — в сгенерированном справочнике CMake, исполняемый синтаксис и владение helper CLI — в справочнике helper CLI, roles и hooks нативных расширений — в справочнике native extensions, а DefinePackage и payload contracts — в справочнике package.

Модель владения

Обычно FOnline конфигурируется из встраивающего игрового проекта. Engine предоставляет CMake stages и helpers; игровой проект задаёт product names, main config, включённые targets, output paths, packages, scripts и platform choices.

Решение об интерфейсе

Используйте существующего владельца, не создавая второй интерфейс. Для CMake option действует такой приоритет: соответствующая переменная окружения FO_, затем существующее значение CMake cache или -D, затем проектное значение SetOption, затем объявленное значение интерфейса по умолчанию. Engine предоставляет CMake stages и helpers; game project предоставляет значения.

Для команд BuildTools/buildtools.py create_parser() владеет основным CLI, парсеры отдельных helper scripts владеют своими command lines, а package.py вместе с package declaration владеет payload contracts. Helper CLI являются revision-pinned implementation interfaces: автоматизация обязана фиксировать ревизию Engine и читать BuildTools/HelperCliInterface.json или его сгенерированный справочник, а не предполагать cross-revision compatibility.

Проверенные исходные пути

BuildTools/Init.cmake
BuildTools/cmake/ProjectInterface.json
BuildTools/cmake/stages/Init.cmake
BuildTools/cmake/stages/ProjectOptions.cmake
BuildTools/cmake/stages/ThirdParty.cmake
BuildTools/cmake/stages/EngineSources.cmake
BuildTools/cmake/stages/Codegen.cmake
BuildTools/cmake/helpers/EnsureCodegenOutputs.cmake.in
BuildTools/cmake/stages/CoreLibs.cmake
BuildTools/cmake/stages/Applications.cmake
BuildTools/cmake/stages/ScriptsAndBaking.cmake
BuildTools/cmake/stages/Packages.cmake
BuildTools/cmake/stages/Finalize.cmake
BuildTools/cmake/helpers/Build.cmake
BuildTools/cmake/helpers/Commands.cmake
BuildTools/cmake/helpers/Options.cmake
BuildTools/cmake/helpers/RunAndLog.cmake
BuildTools/cmake/helpers/State.cmake
BuildTools/cmake/helpers/WriteBuildHash.cmake
BuildTools/codegen.py
BuildTools/EffekseerEditor/build.ps1
BuildTools/managed_runtime_payload.py
BuildTools/codecoverage.py
BuildTools/android_device.py
BuildTools/web/simple-web-server.py
BuildTools/HelperCliInterface.json
BuildTools/docs_helper_cli.py
BuildTools/docs_cmake.py
BuildTools/PackageInterface.json
BuildTools/docs_package.py
BuildTools/tests/validate_package_interface.cmake
BuildTools/tests/validate_project_interface.cmake
BuildTools/package.py
BuildTools/tests/test_package_include.py
BuildTools/msicreator/createmsi.py

Важные следствия:

Не документируйте итоговый список targets одной игры как универсальное поведение Engine.
Предпочитайте обязанности stages и имена options жёстко заданным именам сгенерированных targets.
По возможности проверяйте изменения сборки через preset встраивающего проекта.

Файлы стадий

Поэтапный конвейер находится в BuildTools/cmake/stages/. Порядок стадий, имена entrypoints и проверки hooks во время конфигурации реализованы в BuildTools/Init.cmake. BuildTools/cmake/ProjectInterface.json отражает эту поверхность для сгенерированного справочника стадий, а validate_project_interface.cmake отклоняет расхождения в порядке стадий, entrypoints, hook points и путях к исходникам.

`Init.cmake`

Устанавливает базовую конфигурацию. Стадия напрямую объявляет все публичные project options, затем проверяет обязательные значения и создаёт build hash и общий generation context. BuildTools/cmake/ProjectInterface.json фиксирует те же required inputs, cache types, defaults, allowed values, categories и override precedence для сгенерированного справочника options; структурный тест проверяет наличие каждой смоделированной option в этой стадии. При изменении публичной option обновляйте стадию и manifest вместе.

Manifest содержит независимые backends FO_SPARK_PARTICLES и FO_EFFEKSEER_PARTICLES. Оба по умолчанию равны OFF; при миграции проект может включить один или оба. Backend source files остаются в стабильных списках исходников Engine и защищают реализацию соответствующим macro. Отключённый backend не добавляет third-party target, скомпилированную runtime или Mapper implementation, runtime resource extensions и baker implementation.

На Linux linker исключает статические архивы LibreSSL Engine из dynamic symbol table executable. Managed shim OpenSSL открывает системную libssl для cryptography Roslyn; без этой границы библиотека могла бы связать собственные внутренние вызовы с неверсионированными symbols LibreSSL.

`ProjectOptions.cmake`

Нормализует и проверяет комбинации project-level options. Текущие примеры: проверки code coverage, сочетаний build modes и совместимости scripting/tools, например требование AngelScript support при FO_BUILD_ASCOMPILER.

Начинайте здесь, если комбинацию options нужно отклонить или вывести до создания source lists и targets.

`ThirdParty.cmake`

Добавляет bundled third-party libraries Engine. Комментарий стадии фиксирует установку interceptor для find_package() до вызовов third-party AddSubdirectory(), чтобы vendored libraries не могли незаметно использовать систему host.

Подготовка Managed runtime из исходников зависит от target. Перед каждой такой сборкой buildtools.py удаляет repo-local semaphore задач MSBuild, чтобы дерево, впервые собранное для desktop, не пропустило Android-only task projects и позже не упало с MSB4062. Также передаётся NuGetAudit=false: revision runtime закреплён, warnings являются errors, и новая advisory не должна делать неизменившийся tag невосстановимым. Shipped payload содержит CLR assemblies, а не native packages, которые присутствуют лишь в restore graph runtime repo.

Патчи Mono для Windows x86 и Android возвращают constant false для свойств hardware-intrinsic IsSupported, не реализованных их JIT. Без fallback тело property CoreLib рекурсивно вызывает себя и может переполнить stack до первого кадра. Marker cache Managed runtime включает этот source-patch contract; prebuilt runtime уже должен его содержать.

Windows Mono также повторяет отказавшие suspension/context reads во время stop-the-world, пока thread жив, сообщает о каждом отказе и после пяти секунд завершает процесс вместо пропуска работающего thread. Ready marker _suspend_retry заставляет пересобрать Windows runtime. Кроме того, Windows Mono использует существующий путь определения границ стека через VirtualQuery вместо экспорта GetCurrentThreadStackLimits, появившегося в Windows 8. Иначе статический импорт не даст загрузчику Windows 7 запустить клиент ещё до кода движка. Суффикс ready marker _win7_stack_bounds заставляет пересобрать Windows runtime; prebuilt runtime принимается как есть и уже должен содержать оба патча. Проверка импортов итогового PE охватывает и статически связанный runtime, но не заменяет запуск на настоящей Windows 7. Linux managed builds подключают OpenSSL cryptography shim вместе с native и globalization shims. Контракт runtime safety и компиляции fragments описан в руководстве Managed C#.

Начинайте здесь при добавлении или удалении bundled dependency либо изменении правил изоляции её сборки.

Вложенная сборка Managed runtime берёт меньший из переданных лимитов CMAKE_BUILD_PARALLEL_LEVEL и DOTNET_PROCESSOR_COUNT. BuildTools задаёт последний только в дочернем окружении и добавляет /maxcpucount:N, ограниченный максимумом MSBuild в 1024 узла. Windows MSBuild не соблюдает одну переменную окружения; команды Mono с Environment.ProcessorCount получают исходный бюджет процессоров, без ограничения в 1024. Каждый непустой лимит должен быть десятичным целым от 1 до 65535. Если оба отсутствуют, выбор процессоров не меняется. test_runtime_build_budget.py запускает настоящий MSBuild с большим лимитом wrapper: одной переменной окружения недостаточно для подтверждения бюджета.

`EngineSources.cmake`

Создаёт списки исходников и сгенерированные resource files для последующих стадий. Сюда добавляются source lists слоёв Essentials, Common, Frontend, Client, Server, Tools, Scripting и tests. Здесь же готовятся app icon/resource data, например сгенерированный Windows .rc.

Начинайте здесь, когда новый hand-authored source file должен войти в core library Engine.

`Codegen.cmake`

Создаёт команду code generation и набор outputs. В BuildTools/codegen.py передаются project и Engine metadata, включая main config, build hash, generated output path, project names, embedded data capacity, metadata source files и добавленные common headers.

CodeGeneration отслеживает аргументы, metadata и скрипт генератора через stamp CodeGenTouch. Сгенерированные headers, includes и C++ files объявлены как byproducts: неизменившееся содержимое сохраняет timestamp даже после ForceCodeGeneration, поэтому обновление stamp само по себе не пересобирает потребителей. Перед их запуском EnsureCodegenOutputs.cmake восстанавливает отсутствующие outputs той же командой генератора, в том числе для Makefiles, где одних зависимостей byproducts недостаточно. Ошибка генератора остаётся ошибкой сборки. Изменения аргументов или metadata по-прежнему вызывают генерацию и пересборку потребителей, когда меняется содержимое outputs. test_codegen_cmake_dependencies.py проверяет обычную/принудительную генерацию, инвалидацию, восстановление headers/sources и отказ восстановления с Makefiles и Ninja. Эти проверки конкретных generators не доказывают отсутствие повторной генерации Visual Studio после reconfigure без изменений.

Связанный документ: GeneratedApiAndMetadata.md.

`CoreLibs.cmake`

Создаёт core static libraries из списков, подготовленных в EngineSources.cmake. В зависимости от включённых options текущие обязанности охватывают Essentials, Common, frontend/headless app layers, scripting integration libraries, client/server libraries, baker libraries и testing support.

EngineSources.cmake включает нативный модуль EffekseerCompiler.h/.cpp в BakerLib. При включённых Effekseer particles ParticleBaker напрямую компилирует через него XML .efkproj фиксированной Editor-версии 1.80.5 и получает список referenced resources каждого проекта для snapshot path/size/write-time эффекта в BakeOutput/.baker-cache. Runtime libraries и Web clients не зависят от compiler target или host process: они используют предварительно запечённый .efk. Server-only build больше не включает BakerLib только из-за FO_BUILD_SERVER.

Начинайте здесь при изменении группировки исходников, dependencies библиотек или границ runtime layers.

`Applications.cmake`

Создаёт executable и shared-library applications из Source/Applications/*.cpp. Используются helpers AddExecutableApplication, AddSharedApplication, project variables FO_DEV_NAME, output paths, platform flags и включённые build modes.

В зависимости от options здесь подключаются client, client runtime library, headless variants client, server variants, Mapper, viewers анимаций и частиц, baker, AngelScript compiler, Managed script baker и testing app. Универсального приложения Editor и соответствующей validation target нет.

Effekseer Editor намеренно отсутствует в этой стадии и application target graph. Его отдельный entrypoint BuildTools/EffekseerEditor/build.ps1 конфигурирует и собирает upstream sources независимо от CMake-конфигурации FOnline во встраивающем проекте.

Для Visual Studio/MSBuild test targets стадия запускает test executable через BuildTools/cmake/helpers/RunAndLog.cmake. Helper сохраняет stdout и stderr в <build-dir>/<target>.log и завершает CMake command с реальным process exit code. Так ожидаемая диагностика negative tests сохраняется, а MSBuild не трактует строки со словом error как build failures. Другие generators запускают executable напрямую.

Native-конфигурации Windows, Linux и macOS без cross-compilation также собирают FOnlineResourcePackHash перед baker и CMake package targets. Эта host-only C ABI library не зависит от Engine allocator, profiling и sanitizer runtimes; она не линкуется с игровыми приложениями и не входит в их payload. Отдельная сборка: cmake -S BuildTools/resource-pack-hash -B <build> и cmake --build <build>. См. hash backend упаковщика.

См. Applications.

`ScriptsAndBaking.cmake`

Создаёт custom targets для компиляции scripts и baking ресурсов. Текущие обязанности:

AngelScript compilation через project AS compiler target при включённом AngelScript scripting.
Компиляция Managed C# через standalone project ManagedScriptBaker при включённом FO_MANAGED_SCRIPTING. CompileManagedScripts выполняется после ForceCodeGeneration, использует настроенные managed source dirs/references/analyzers и создаёт target assemblies каждого pack вместе с API/ABI .gen.cs, .gen.csproj и .gen.sln. Setup runtime и подготовка payload являются отдельными targets.
Resource baking через project baker target.
Поддержка build-hash/write-hash для baked resources.
Обычные и принудительные bake targets.
Публичный helper AddBakingTarget(<target> [SUB_CONFIG <name>] [FORCE] [COMMENT <text>]) для принадлежащих проекту вариантов запекания. Вызывайте его после SetupScriptsAndBaking(), когда project baker уже существует; каждая добавленная цель переиспользует стандартные зависимость от codegen, рабочий каталог output, применение конфигурации и обновление resource build hash.

Связанные документы: Baking Pipeline и Scripting.

`Packages.cmake`

Поля бинарника записываются на месте с проверкой размера payload и границ поля до каждой записи. Граница отказа отдельного поля и Engine-owned регрессии описаны в руководстве packaging.

Локальные wrappers package-web-debug и package-android-debug передают -resource-pack-compress-level 1 для Raw payloads; сжатие distribution bundles по-прежнему берётся из project config. test_buildtools_debug_packaging.py проверяет сформированные команды настоящим parser упаковщика для Web и всех поддерживаемых Android architectures, нескольких debug configurations и путей с пробелами.

Создаёт package targets из FO_PACKAGES и вызывает BuildTools/package.py с project context: main config, build hash, developer name, nice name, input/output paths, platform/architecture/config data и optional output postfix текущей записи BINARY.

Clauses декларации DefinePackage, допустимые runtime targets/platforms/architectures, pack tokens, support status и payload effects моделируются в BuildTools/PackageInterface.json и выводятся в сгенерированном справочнике пакетов. Manifest является данными документации и проверки; runtime authority остаётся у DefinePackage, Packages.cmake и package.py. Focused и структурные тесты сопоставляют смоделированные grammar и dimensions с этими реализациями. Встраивающий проект всё равно владеет выбором допустимых комбинаций.

POSTFIX <value> следует за одной clause BINARY и не наследуется соседними entries. Значение должно совпадать с FO_BINARY_OUTPUT_POSTFIX, использованным при сборке binary: обе стороны участвуют в имени input directory и packaged runtime identity. Package architecture keys win32-win7 и win64-win7 разрешаются в канонические binary architectures win32 и win64; legacy toolset выбирается в buildtools.py, а явный postfix, например POSTFIX Win7, разделяет имена Raw/Zip/Wix. Перед packaging или publication запускайте BuildTools/check_windows7_imports.py для каждого связанного Win7 PE.

package.py владеет переиспользуемой раскладкой package payload и optional post-processing. Он записывает логические file modes target 0644/0755 независимо от host filesystem, напрямую передаёт их writers ZIP/TAR и объединяет records Raw/Root разных package parts в versioned package-root publication handoff .lf-package-modes.json. Paths manifest должны быть нормализованными POSIX-relative payload paths; absolute, drive-qualified, escaping paths и paths с backslash завершают проверку ошибкой. Publisher raw trees обязан применить handoff и исключить его из публичного payload.

Для Windows Client package с pack Wix package.py после staging Raw вызывает msicreator/createmsi.py: MSI получает временный marker INSTALLED, используемый разрешением writable path установленного client, регистрирует deep-link URI scheme, создаёт Start Menu и Desktop shortcuts и icon в Add/Remove Programs и всегда показывает редактируемый диалог выбора installation directory. Оба поддерживаемых build hosts используют одно и то же inline-описание диалога, поэтому он не пропадает, когда production собирает через wixl на Linux. MSI обязателен при запросе Wix. POSIX hosts требуют wixl 0.102 или новее вместе с bundled extension ui. Windows ищет FO_WIX_ROOT, подготовленный соседний directory wix3, затем candle/light в PATH; buildtools.py prepare-workspace wix загружает закреплённый ThirdParty/wix release WiX v3 в этот workspace с обычными mirror и SHA-256 checks. Windows light сначала выполняет обычную ICE validation и повторяет link один раз с -sval только при точном сообщении о недоступности Windows Installer service; ошибки authoring, linker, обычной ICE и fallback остаются фатальными. Отсутствие toolset или ошибка generator/build завершает packaging ошибкой. В Debian/Ubuntu wixl поставляется отдельным apt package wixl, а не msitools; common-packages включает php-cli в общий runner contract. Installer values читаются из конфига встраивающего проекта, поэтому packager остаётся game-agnostic:

Сгенерированный диалог выбора каталога выполняется после CostFinalize; привязка только перед ProgressDlg может заставить wixl показать его при ещё пустом INSTALLDIR (ошибка MSI 2343). Переиспользуемый контракт порядка и проверки на поддерживаемых hosts описаны в упаковке и выпуске.

product/manufacturer/comments name берётся из Common.GameName с fallback к package nice name;
ProductVersion берётся из Common.GameVersion, а $FILE{...} разрешается относительно main config directory, поэтому $FILE{VERSION} даёт реальную числовую версию, а не fallback 0.0.0;
deep-link URI scheme берётся из Auth.UriScheme;
стабильный WiX UpgradeCode берётся из Packaging.MsiUpgradeCode и не должен меняться после первого выпуска MSI;
icon Add/Remove Programs берётся из optional Packaging.AppIcon;
имя install directory и MSI base name берутся из package nice name.

Product использует InstallScope="perUser". Компоненты shortcuts Start Menu и Desktop имеют разные key paths в HKCU, регистрация PATH задаёт System="no", а сгенерированные directory components включают cleanup при uninstall. Явный INSTALLDIR, переданный в msiexec, имеет высший приоритет. Иначе первая интерактивная установка предпочитает путь, запомненный предыдущим MSI, а затем per-user writable fallback %LOCALAPPDATA%\<Common.GameName>. Выбранный путь сохраняется в HKCU\Software\<nice-name>\InstallLocation, а экран выбора каталога всегда допускает прямое редактирование или обзор, включая явный выбор Program Files. Standalone MSI не обращается к installation infrastructure Steam или другого магазина.

Обновление MSI намеренно сохраняет запомненный путь в Program Files вместо переноса существующего дерева. Обновлённый marker INSTALLED по-прежнему направляет cache, logs, resources и обновления native runtime в per-user writable overlay, описанный в Client Updater, поэтому сохранённое расположение executable не мешает последующим self-updates.

Portable Raw/Zip artifacts завершаются до MSI и не содержат marker INSTALLED, поэтому остаются portable.

Managed class libraries остаются resource payload, а не binary companions.

package.py пишет каждый не-Embedded target pack как .fores из отфильтрованного loose bake output; Embedded остаётся ZIP внутри executable. Baking.ResourcePackCompressLevel и Baking.ResourcePackMinCompressGain управляют сжатием .fores, Baking.BundleCompressLevel — Embedded и внешними bundles. Для одного запуска служат -resource-pack-compress-level и -bundle-compress-level. Формат и правила выбора/восстановления updater описаны в формате пакетов ресурсов и разделении client runtime и updater. Когда несколько binary variants разделяют один updater target, package.py проверяет каждое подготовленное дерево ManagedRuntime и выбирает наименее квалифицированную подходящую binary entry — обычно default Release build — для единственного target-wide resource pack. Независимо собранные эквивалентные CoreLib payloads не обязаны быть byte-identical.

Embedding build может задать FO_RESOURCE_ARCHIVE_CACHE_HELPER как Python helper с интерфейсом restore|store|release --key <sha256> --archive <path>. Ключ охватывает стабильные имена и содержимое entries вместе с compression level. Восстановленный или только что записанный archive всегда проходит ту же проверку точного entry list и CRC; cache miss и результат недоступности optional cache переходят к локальному созданию, а прочие failures helper остаются packaging errors. Повторный идентичный archive в одном процессе packaging использует первый проверенный результат.

-resource-pack-jobs N или FO_RESOURCE_PACK_JOBS (по умолчанию 1) ограничивает независимые архивы .fores положительным числом N процессов с spawn. Коллизии pack name/destination сохраняют порядок внутри одного worker; каждый archive по-прежнему проходит полную payload validation. Workers завершаются до переписывания runtime packs или очистки неудавшегося package. Batching, cache state, лимиты ресурсов и неизменную границу воспроизводимости см. в Packaging and Release.

Когда несколько package parts добавляются в один SingleZip, байт-идентичные файлы с одним archive path объединяются в одну entry. Разное содержимое по одному path является packaging error; packager не создаёт неоднозначные duplicate ZIP names.

В универсальной package schema нет binary role EffekseerEditor. Отдельно собранные tools объявляются рядом с BINARY через INCLUDE <source-path-glob> <target-path-in-pack>. Source glob задаётся относительно FO_OUTPUT_PATH. После сборки обычных binary parts generic packager заменяет included target tree и обновляет существующий SingleZip без duplicate или stale entries. Этот путь покрыт BuildTools/tests/test_package_include.py.

При изменении wiring package target начинайте в Packages.cmake. При изменении declaration vocabulary, поддерживаемых комбинаций, payload layout, artifact behavior, packager arguments или package-time installer metadata начинайте в BuildTools/PackageInterface.json и package.py.

`Finalize.cmake`

Выполняет итоговую организацию solution/project и поздний reporting. Текущие обязанности включают target folder grouping, optional copy настроек ReSharper, third-party dummy grouping и подробный вывод cache variables при включённом FO_VERBOSE_BUILD.

Начинайте здесь для итоговой организации targets или post-generation diagnostics, а не для source ownership или проверки build features.

Вспомогательные файлы

Переиспользуемые helpers находятся в BuildTools/cmake/helpers/:

Build.cmake — helpers создания build/target, включая executable-only /LARGEADDRESSAWARE для Windows x86; см. пределы адресного пространства и проверку.
Commands.cmake — helpers command targets.
Options.cmake — helpers options/values.
RunAndLog.cmake — внутренний script-mode process runner, сохраняющий test output и передающий exit code.
State.cmake — поддержка состояния и hooks поэтапного pipeline.
WriteBuildHash.cmake — записывает настроенный FO_BUILD_HASH, переданный как BUILD_HASH, в маркеры native binaries и ресурсов. При записи он не перечитывает Git HEAD и не выбирает новую случайную идентичность. Поэтому маркеры совпадают с идентичностью, встроенной в native applications при конфигурации, в том числе для исходных архивов без Git и путей с пробелами. BuildTools/tests/test_cmake_build_hash.py проверяет реальные скомпилированные приложения и обе стандартные цели baking до и после смены Git revision.

Если стадии нужно переиспользуемое поведение, добавляйте helper здесь вместо копирования логики между stages.

Расположение в helpers не делает command публичной. Документированной поверхностью встраивающего проекта являются только выбранные команды из BuildTools/cmake/ProjectInterface.json, выведенные в справочнике helper. Остальные helper commands остаются внутренними деталями реализации.

Hooks стадий

Комментарии стадий используют соглашение:

AddStageHook(<StageName> Pre|Post <macro-name>)

Используйте hooks, когда встраивающему проекту или последующему refactor нужно расширить поведение стадии без изменения её середины. Документируйте hook рядом с owning stage или в project docs, если он game-specific.

Документированный inventory поддерживаемых stage names, entrypoints и hook positions находится в сгенерированном справочнике стадий и hooks; configure-time authority остаётся у BuildTools/Init.cmake.

Маршрутизация изменений

Новая project option: объявление в Init.cmake, проверка сочетаний в ProjectOptions.cmake и соответствующие документационные данные в BuildTools/cmake/ProjectInterface.json.
Новая vendored dependency: ThirdParty.cmake.
Новая project-local dependency или role link: ProjectDependencies.md, потребляемый список FO_*_LIBS закреплённой ревизии и target/package matrix встраивающего проекта.
Новый engine source file: EngineSources.cmake и, возможно, CoreLibs.cmake.
Новое generated metadata/API behavior: Codegen.cmake и GeneratedApiAndMetadata.md.
Новая helper command или argument: executable create_parser(), BuildTools/HelperCliInterface.json, справочнике helper CLI и BuildTools/docs_helper_cli.py.
Новый project-native source role, hook или binding rule: BuildTools/NativeExtensionInterface.json, NativeExtensions.md, generated/native-extension/index.md и BuildTools/docs_native_extension.py.
Новое script compile или resource bake behavior: ScriptsAndBaking.cmake, Baking Pipeline, Scripting и backend-specific руководство AngelScript либо Managed C#.
Новый executable/tool entry point: Applications.cmake и Applications.
Рецепты сборки auxiliary tool: BuildTools/buildtools.py build-auxiliary, BuildTools/EffekseerEditor/build.ps1 и Tools.md.
Новая package declaration, support combination, layout или artifact: BuildTools/PackageInterface.json, Packages.cmake, BuildTools/package.py, сгенерированном справочнике пакетов, при необходимости BuildTools/msicreator/createmsi.py, а также platform docs.
Итоговая организация targets или verbose diagnostics: Finalize.cmake.

Чек-лист проверки

Для изменений BuildTools:

Выполните cmake -P BuildTools/tests/validate_project_interface.cmake при изменениях project interface.
После регенерации CMake reference выполните python BuildTools/tests/test_docs_cmake.py и python BuildTools/docs_cmake.py --check.
Выполните configure из корня реального встраивающего проекта.
Используйте самый узкий preset, затрагивающий изменённую stage.
При изменении source lists проверьте сборку затронутой target.
При изменении codegen проверьте generated files и script API consumers.
При изменении baking выполните normal и forced bake paths, если применимо.
Для изменений Effekseer Editor выполните buildtools.py build-auxiliary effekseer-editor Release на Windows win64, проверьте staged payload managed/native/resources и package INCLUDE, если изменилась layout developer package.
Для package changes выполните затронутую package target и проверьте output layout; для WiX/MSI также проверьте generated installer config/registry values или соберите installer на host с WiX/wixl.
Для изменений package interface выполните python BuildTools/tests/test_docs_package.py, cmake -P BuildTools/tests/validate_package_interface.cmake и после регенерации python BuildTools/docs_package.py --check.
Для изменений native extension interface выполните python BuildTools/tests/test_docs_native_extension.py, cmake -P BuildTools/tests/validate_native_extension_interface.cmake и после регенерации python BuildTools/docs_native_extension.py --check.
Сравните все регенерированные модели API/CMake/main-CLI/package/helper-CLI/native-extension с выбранной base через BuildTools/docs_contract_diff.py и заполните необходимую contract disposition.
При изменении docs запустите проверки ссылок.
До сообщения о завершении выполните git diff --check.