Компиляция с помощью .NET
Требования
-
Вы можете использовать
dotnet --infoдля проверки установленных версий .NET SDK.
Включить модуль .NET
Примечание
Поддержка C# для Godot исторически использовала среду выполнения Mono вместо .NET Runtime, и внутри многие вещи по-прежнему называются mono вместо dotnet или иначе упоминаются как mono.
По умолчанию модуль .NET отключен при сборке. Чтобы включить его, добавьте параметр module_mono_enabled=yes в командную строку SCons, в остальном следуя инструкциям по сборке нужных исполняемых файлов Godot.
Сгенерировать glue
Часть исходных файлов управляемых библиотек генерируется из ClassDB. Эти исходные файлы необходимо сгенерировать до сборки управляемых библиотек. Их можно сгенерировать с помощью любого исполняемого файла редактора Godot с поддержкой .NET, запустив его с параметрами --headless --generate-mono-glue и указав путь к выходному каталогу. Этот путь должен быть modules/mono/glue в каталоге Godot:
<godot_binary> --headless --generate-mono-glue modules/mono/glue
Эта команда заставит Godot сгенерировать привязки C# для API Godot в modules/mono/glue/GodotSharp/GodotSharp/Generated, а также привязки C# для инструментов редактора в modules/mono/glue/GodotSharp/GodotSharpEditor/Generated. После генерации этих файлов вы сможете собрать управляемые библиотеки Godot для всех желаемых целевых платформ, не повторяя этот процесс.
<godot_binary> относится к двоичному файлу редактора, скомпилированному с включённым модулем .NET. Его точное имя будет зависеть от вашей системы и конфигурации, но должно иметь вид bin/godot.<platform>.editor.<arch>.mono, например, bin/godot.linuxbsd.editor.x86_64.mono или bin/godot.windows.editor.x86_32.mono.exe. Обратите особое внимание на суффикс .mono! Если вы ранее компилировали Godot без поддержки .NET, у вас могли быть похожие имена двоичных файлов без этого суффикса. Эти двоичные файлы нельзя использовать для генерации связующего .NET-файла.
Примечание
Источники связующего компонента необходимо генерировать заново при каждом изменении API, зарегистрированного в ClassDB. Например, при регистрации нового метода в API скриптов или изменении одного из параметров такого метода. Godot выдаст ошибку при запуске, если API между ClassDB и источниками связующего компонента не совпадают.
Создание управляемых библиотек
После создания связующего звена .NET вы можете собрать управляемые библиотеки с помощью скрипта build_assemblies.py:
./modules/mono/build_scripts/build_assemblies.py --godot-output-dir=./bin
Если все прошло хорошо, то в каталоге bin должен был быть создан каталог GodotSharp, содержащий управляемые библиотеки.
Примечание
По умолчанию все сборки для разработки имеют общий номер версии, что может вызывать проблемы с кэшированием пакетов NuGet. Чтобы решить эту проблему, используйте GODOT_VERSION_STATUS, чтобы назначить каждой сборке уникальную версию, или удаляйте GodotNuGetFallbackFolder после каждой сборки, чтобы очистить кэш пакетов.
В отличие от "классических" сборок Godot, при сборке с включённым модулем .NET (и в зависимости от целевой платформы) может быть создан каталог с данными как для редактора, так и для экспортированных проектов. Этот каталог важен для корректной работы и должен распространяться вместе с Godot. Подробнее об этом каталоге см. в разделе Data directory.
Платформа сборки
Укажите аргумент --godot-platform=<platform>, чтобы указать, для какой платформы собираются библиотеки. Для сборки для текущей системы этот аргумент можно пропустить.
В настоящее время это контролирует только включение поддержки Visual Studio как внешнего редактора, в остальном библиотеки идентичны.
Пакеты NuGet
Сборки API, генераторы исходного кода и SDK для проектов MSBuild распространяются в виде пакетов NuGet. Всё это прозрачно для пользователя, но может усложнить разработку.
Чтобы использовать Godot с версией этих пакетов, находящейся в разработке, необходимо создать локальный источник NuGet, в котором MSBuild сможет их найти.
Сначала выберите расположение для локального источника NuGet. Если у вас нет предпочтений, создайте пустой каталог в одном из следующих рекомендуемых мест:
В Windows:
C:\Users\<имя пользователя>\MyLocalNugetSourceВ Linux, *BSD и т. д.
~/MyLocalNugetSource
Этот путь далее будет обозначаться как <my_local_source>.
После выбора каталога выполните эту команду .NET CLI, чтобы настроить NuGet на использование локального источника:
dotnet nuget add source <my_local_source> --name MyLocalNugetSource
При запуске скрипта build_assemblies.py передайте <my_local_source> параметру --push-nupkgs-local:
./modules/mono/build_scripts/build_assemblies.py --godot-output-dir ./bin --push-nupkgs-local <my_local_source>
Этот параметр гарантирует добавление пакетов в указанный локальный источник NuGet и удаление конфликтующих версий пакетов из кэша NuGet. Рекомендуется всегда использовать этот параметр при сборке решений C# во время разработки, чтобы избежать ошибок.
Сборка без зависимости от устаревших функций (NO_DEPRECATED)
При сборке Godot без устаревших классов и функций, т.е. с аргументом deprecated=no для scons, управляемые библиотеки также должны быть собраны без зависимостей от устаревшего кода. Это достигается передачей аргумента --no-deprecated:
./modules/mono/build_scripts/build_assemblies.py --godot-output-dir ./bin --push-nupkgs-local <my_local_source> --no-deprecated
Поддержка Двойной Точности (REAL_T_IS_DOUBLE)
При сборке Godot с поддержкой двойной точности, т. е. аргументом precision=double для scons, управляемые библиотеки необходимо настроить для соответствия, передав аргумент --precision=double:
./modules/mono/build_scripts/build_assemblies.py --godot-output-dir ./bin --push-nupkgs-local <my_local_source> --precision=double
Примеры
Пример (Windows)
# Build editor binary
scons platform=windows target=editor module_mono_enabled=yes
# Build export templates
scons platform=windows target=template_debug module_mono_enabled=yes
scons platform=windows target=template_release module_mono_enabled=yes
# Generate glue sources
bin/godot.windows.editor.x86_64.mono --headless --generate-mono-glue modules/mono/glue
# Build .NET assemblies
./modules/mono/build_scripts/build_assemblies.py --godot-output-dir ./bin --push-nupkgs-local <my_local_source> --godot-platform=windows
Пример (Linux, *BSD)
# Build editor binary
scons platform=linuxbsd target=editor module_mono_enabled=yes
# Build export templates
scons platform=linuxbsd target=template_debug module_mono_enabled=yes
scons platform=linuxbsd target=template_release module_mono_enabled=yes
# Generate glue sources
bin/godot.linuxbsd.editor.x86_64.mono --headless --generate-mono-glue modules/mono/glue
# Generate binaries
./modules/mono/build_scripts/build_assemblies.py --godot-output-dir ./bin --push-nupkgs-local <my_local_source> --godot-platform=linuxbsd
Каталог данных
Каталог данных является зависимостью для исполняемых файлов Godot, собранных с включенным модулем .NET. Он содержит важные файлы для корректной работы Godot. Он должен распространяться вместе с исполняемым файлом Godot.
Редактор
Имя каталога данных для редактора Godot всегда будет GodotSharp. Этот каталог содержит подкаталог Api со сборками API Godot и подкаталог Tools с инструментами, необходимыми редактору, такими как сборки GodotTools и их зависимости.
В macOS, если редактор Godot распространяется в виде пакета, каталог GodotSharp может быть помещен в каталог <имя_пакета>.app/Contents/Resources/ внутри пакета.
Экспорт шаблонов
Каталог данных для экспортируемых проектов создаётся редактором во время экспорта. Он называется data_<APPNAME>_<ARCH>, где <APPNAME> — имя приложения, указанное в настройках проекта application/config/name, а <ARCH> — текущая архитектура экспорта.
В случае экспорта нескольких архитектур будет создано несколько таких каталогов данных.
Параметры командной строки
Ниже приведен список параметров командной строки, доступных при сборке с использованием модуля .NET:
module_mono_enabled=yes | no
Соборка Godot с включенным модулем .NET.