Attention: Here be dragons

This is the latest (unstable) version of this documentation, which may document features not available in or compatible with released stable versions of Godot.

Checking the stable version of the documentation...

Компіляція для Linux, *BSD

Дивись також

На цій сторінці описано, як скомпілювати редактор Linux і експортувати двійкові файли шаблону з джерела. Якщо ви натомість хочете експортувати свій проект у Linux, прочитайте Експорт на Linux.

Вимоги

Для того щоб зібрати проєкт під Linux чи який-небудь інший вид Unix системи, вам знадобляться:

  • GCC 9+ або Clang 6+.

  • Python 3.9+.

  • SCons 4.4+ build system.

  • pkg-config (використовується для виявлення бібліотек розробки, перелічених нижче).

  • Бібліотеки розробки:

    • X11, Xcursor, Xinerama, Xi та XRandR.

    • Wayland і Wayland-сканер.

    • Mesa.

    • ALSA.

    • PulseAudio.

  • За бажанням - libudev (зберіть з параметром udev=yes).

Дивись також

Щоб отримати вихідний код Godot для компіляції, перегляньте Отримання джерела.

Для загального огляду використання SCons для Godot див. Знайомство з системою побудови.

Команди для різних дистрибутивів

apk add \
  scons \
  pkgconf \
  gcc \
  g++ \
  libx11-dev \
  libxcursor-dev \
  libxinerama-dev \
  libxi-dev \
  libxrandr-dev \
  mesa-dev \
  eudev-dev \
  alsa-lib-dev \
  pulseaudio-dev

Компілювання

Відкрийте термінал, перейдіть до кореневої директорії проєкту та введіть:

scons platform=linuxbsd

Примітка

До Godot 4.0 ціль Linux/*BSD називалася x11 замість linuxbsd. Якщо ви хочете скомпілювати Godot 3.x, обов’язково використовуйте гілку 3.x цієї документації <https://docs.godotengine.org/en/3.6/development/compiling/compiling_for_x11.html>`__.

Порада

Якщо ви компілюєте Godot, щоб внести зміни або зробити внесок у механізм, ви можете використати параметри SCons dev_build=yes або dev_mode=yes. Перегляньте Псевдоніми розробки та виробництва для отримання додаткової інформації.

Якщо все піде добре, отриманий двійковий виконуваний файл буде розміщено в підкаталозі "bin". Цей виконуваний файл містить весь механізм і працює без будь-яких залежностей. Після його виконання з’явиться менеджер проекту.

Примітка

Якщо ж вам хочеться зібрати проєкт використовуючи Clang а не GCC, то використайте команду:

scons platform=linuxbsd use_llvm=yes

Використання Clang є обов’язковою умовою для OpenBSD, інакше шрифти не збиратимуться. Для пристроїв з архітектурою RISC-V використовуйте компілятор Clang замість компілятора GCC.

Примітка

Компіляція на деяких платформах, таких як OpenBSD, може вимагати більше пам'яті, ніж доступно за замовчуванням. Щоб збільшити ліміт пам'яті на OpenBSD у межах максимуму для поточного користувача, виконайте команду ulimit -d {new amount in kB}.

Порада

Якщо ви компілюєте Godot для використання у виробництві, ви можете зробити кінцевий виконуваний файл меншим і швидшим, додавши опцію SCons production=yes. Це дозволяє додатково оптимізувати компілятор і оптимізувати час зв’язку.

LTO потребує деякий час для запуску та вимагає близько 7 ГБ доступної оперативної пам’яті під час компіляції. Якщо вам не вистачає пам’яті з наведеним вище параметром, використовуйте production=yes lto=none або production=yes lto=thin для легкої, але менш ефективної форми LTO.

Примітка

Якщо ви хочете використовувати окремі параметри редактора для власних збірок Godot та офіційних випусків, ви можете ввімкнути Автономний режим, створивши файл під назвою ._sc_ або _sc_ у bin/ папка.

Компіляція з підтримкою AccessKit

AccessKit забезпечує підтримку програм зчитування з екрана.

За замовчуванням Godot зібрано з динамічно зв'язаним AccessKit. Ви можете використовувати його, розмістивши accesskit.so поруч із виконуваним файлом.

Примітка

Ви також можете використовувати динамічно зв'язаний AccessKit із шаблонами експорту, перейменуйте SO на accesskit.{architecture}.so та розмістіть їх поруч із виконуваними файлами шаблонів експорту, і бібліотеки будуть автоматично скопійовані під час процесу експорту.

Щоб скомпілювати Godot зі статично зв'язаним AccessKit:

  • Завантажте попередньо створені статичні бібліотеки з godot-accesskit-c-static library та розпакуйте їх.

  • Під час збірки Godot додайте accesskit_sdk_path={path}, щоб вказати SCons, де шукати бібліотеки AccessKit:

    scons platform=linuxbsd accesskit_sdk_path=<...>

Примітка

За бажанням ви можете самостійно створити бібліотеки godot-angle-static, виконавши наступні дії:

  1. Клонуйте каталог godot-accesskit-c-static та перейдіть до нього.

  2. Виконайте таку команду:

cd accesskit-c
cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build
cmake --install build

Статичну бібліотеку AccessKit слід зібрати за допомогою того ж компілятора, який ви використовуєте для збірки Godot.

Запуск безголової/серверної збірки

Щоб запустити програму в headless режимі, який забезпечує функціональність редактора для експорту проектів автоматизованим способом, використовуйте звичайну збірку:

scons platform=linuxbsd target=editor

А потім використовуйте аргумент командного рядка --headless:

./bin/godot.linuxbsd.editor.x86_64 --headless

Щоб скомпілювати збірку налагоджувального сервера, яку можна використовувати з remote debugging tools, використовуйте:

scons platform=linuxbsd target=template_debug

Щоб скомпілювати збірку сервера, оптимізовану для роботи виділених ігрових серверів, використовуйте:

scons platform=linuxbsd target=template_release production=yes

Збірка шаблонів експорту

Попередження

Бінарні файли Linux зазвичай не працюють на дистрибутивах, які є старішими за дистрибутив, на якому вони були створені. Якщо ви бажаєте розповсюджувати бінарні файли, які працюють на більшості дистрибутивів, вам слід створити їх на старому дистрибутиві, такому як Ubuntu 20.04. Ви можете використовувати віртуальну машину або контейнер для налаштування відповідного середовища побудови.

Щоб створити шаблони експорту Linux або *BSD, запустіть систему збирання з такими параметрами:

  • (32 біт)

scons platform=linuxbsd target=template_release arch=x86_32
scons platform=linuxbsd target=template_debug arch=x86_32

  • (64 біт)

scons platform=linuxbsd target=template_release arch=x86_64
scons platform=linuxbsd target=template_debug arch=x86_64

Візьміть до уваги: збірка для протилежної платформи (64/32) може бути складним завданням, та потребувати входу в середовище chroot.

Щоб створити стандартні шаблони експорту, отримані файли в папці bin/ необхідно скопіювати до:

$HOME/.local/share/godot/export_templates/<version>/

і має таку назву (навіть для *BSD, який Godot розглядає як «Linux/X11»):

linux_debug.arm32
linux_debug.arm64
linux_debug.x86_32
linux_debug.x86_64
linux_release.arm32
linux_release.arm64
linux_release.x86_32
linux_release.x86_64

Однак, якщо ви пишете власні модулі або власний код C++, можливо, вам варто налаштувати свої бінарні файли як власні шаблони експорту в меню експорту проекту. Щоб налаштувати це, потрібно ввімкнути Додаткові параметри.

../../../_images/lintemplates.webp

Вам навіть не потрібно копіювати їх файли, достатньо просто вказати їх в підтеці bin/ з теки, де знаходиться код Godot, щоб наступного разу, при збірці, ваші шаблони будуть додані автоматично.

Крос-компіляція для пристроїв RISC-V

Для крос-компіляції Godot для пристроїв RISC-V нам потрібно налаштувати такі елементи:

  • riscv-gnu-toolchain. Хоча ми не будемо використовувати це безпосередньо, воно надає нам sysroot, а також файли заголовків і бібліотек, які нам будуть потрібні. Є багато версій на вибір, однак чим старіший інструментарій, тим суміснішими будуть наші кінцеві бінарні файли. Якщо ви сумніваєтеся, використовуйте цю версію і завантажте riscv64-glibc-ubuntu-20.04-gcc-nightly-2023.07.07-nightly.tar.gz. Розпакуйте його десь і запам'ятайте шлях до нього.

  • mold. Цей швидкий компонувальник є єдиним, який правильно зв’язує результуючий двійковий файл. Завантажте його, розпакуйте та обов’язково додайте його папку bin до свого ШЛЯХУ. Запустіть mold --help | grep support, щоб перевірити, чи ваша версія Mold підтримує RISC-V. Якщо ви не бачите RISC-V, можливо, ваш Mold потрібно оновити.

Щоб спростити посилання на наш інструментальний ланцюжок, ми можемо встановити таку змінну середовища:

export RISCV_TOOLCHAIN_PATH="path to toolchain here"

Таким чином, нам не доведеться вручну встановлювати розташування каталогу кожного разу, коли ми хочемо посилатися на нього.

Після всіх наведених вище налаштувань ми готові створити Godot.

Перейдіть до кореневого каталогу вихідного коду та виконайте таку команду збірки:

PATH="$RISCV_TOOLCHAIN_PATH/bin:$PATH" \
scons arch=rv64 use_llvm=yes linker=mold lto=none target=editor \
    ccflags="--sysroot=$RISCV_TOOLCHAIN_PATH/sysroot --gcc-toolchain=$RISCV_TOOLCHAIN_PATH -target riscv64-unknown-linux-gnu" \
    linkflags="--sysroot=$RISCV_TOOLCHAIN_PATH/sysroot --gcc-toolchain=$RISCV_TOOLCHAIN_PATH -target riscv64-unknown-linux-gnu"

Примітка

RISC-V GCC має помилки з його атомарними операціями, які заважають йому правильно компілювати Godot. Ось чому замість нього використовується Clang. Переконайтеся, що він може скомпілюватися до RISC-V. Ви можете перевірити, виконавши цю команду clang -print-targets, переконайтеся, що ви бачите riscv64 у списку цілей.

Попередження

Наведений вище код містить додавання $RISCV_TOOLCHAIN_PATH/bin до PATH, але лише для наступної команди scons. Оскільки riscv-gnu-toolchain використовує власний Clang, розташований у папці bin, додавання $RISCV_TOOLCHAIN_PATH/bin до змінної середовища PATH вашого користувача може заблокувати вам доступ до іншої версії Clang, якщо вона встановлена. З цієї причини не рекомендується робити додавання папки bin постійним. Ви також можете опустити рядок PATH="$RISCV_TOOLCHAIN_PATH/bin:$PATH", якщо ви хочете використовувати scons із самостійно встановленою версією Clang, але це може мати проблеми сумісності з riscv-gnu-toolchain.

Команда подібна за своєю природою, але з деякими ключовими змінами. ccflags і linkflags додають додаткові позначки до збірки. --sysroot вказує на папку, що імітує систему Linux, вона містить усі заголовки, бібліотеки та файли .so, які використовуватиме Clang. --gcc-toolchain повідомляє Clang, де знаходиться повний ланцюжок інструментів, а -target riscv64-unknown-linux-gnu вказує Clang цільову архітектуру та ОС, для яких ми хочемо створити.

Якщо все пройшло добре, тепер ви повинні побачити каталог bin, а в ньому двійковий файл, подібний до такого:

godot.linuxbsd.editor.rv64.llvm

Тепер ви можете скопіювати цей виконуваний файл на свій улюблений пристрій RISC-V, а потім запустити його там подвійним клацанням миші, що має відкрити менеджер проекту.

Якщо пізніше ви вирішите скомпілювати шаблони експорту, скопіюйте наведену вище команду збірки, але змініть значення target на template_debug для збірки налагодження або template_release для збірки випуску.

Використання Clang та LLD для пришвидшення розробки

Ви можете збудувати Godot з Clang та LLD. Вони мають пару переваг у порівнянні зі стандартною зв'язкою GCC + GNU ld:

  • LLD збирає Godot значно швидше у порівнянні з to GNU ld чи gold. Таким чином збирання проходить швидшими ітераціями.

  • Clang дає корисніші повідомлення про помилки ніж GCC.

Для цього встановіть Clang та пакет lld з менеджера пакетів вашого дистрибутива, а потім скористайтеся такою командою SCons:

scons platform=linuxbsd use_llvm=yes linker=lld

Щойно побудова буде завершена, в теці bin/ буде створений новий бінарний файл із суфіксом .llvm.

It's still recommended to use GCC for production builds as it's the compiler used for official builds and is more rigorously tested.

Якщо виникає ця помилка:

/usr/bin/ld: cannot find -l:libatomic.a: No such file or directory

Є два рішення:

  • У вашій команді SCons додайте параметр use_static_cpp=no.

  • Дотримуйтеся цих інструкцій, щоб налаштувати, створити та встановити libatomic_ops. Потім скопіюйте /usr/lib/libatomic_ops.a до /usr/lib/libatomic.a або створіть програмне посилання на libatomic_ops командою ln -s /usr/ lib/libatomic_ops.a /usr/lib/libatomic.a. М'яке посилання може гарантувати, що останній libatomic_ops буде використовуватися без необхідності копіювати його кожного разу, коли він оновлюється.

Використання цвілі для швидшого розвитку

Для ще швидшого зв’язування порівняно з LLD ви можете використовувати mold. mold можна використовувати з GCC або Clang.

sudo apt-get update
sudo apt-get install -y mold

Після встановлення mold, використовуйте таку команду SCons під час компіляції Godot:

scons platform=linuxbsd linker=mold

Використання системних бібліотек для прискорення розробки

Godot об’єднує вихідний код різних сторонніх бібліотек. Натомість ви можете використовувати системні версії сторонніх бібліотек. Це робить двійковий файл Godot швидшим для зв’язування, оскільки сторонні бібліотеки зв’язуються динамічно. Таким чином, їх не потрібно статично пов’язувати кожного разу, коли ви створюєте механізм (навіть при невеликих поступових змінах).

Однак не всі дистрибутиви Linux мають пакунки для бібліотек сторонніх розробників (або вони можуть бути неоновленими).

Перехід до системних бібліотек може скоротити час зв’язування на кілька секунд на повільних процесорах, але це вимагає ручного тестування залежно від вашого дистрибутива Linux. Крім того, можливо, ви не зможете використовувати системні бібліотеки для всього через помилки в пакетах системної бібліотеки (або в системі збірки, оскільки ця функція менш перевірена).

Щоб скомпілювати Godot із системними бібліотеками, встановіть ці залежності поверх залежностей, перелічених у Команди для різних дистрибутивів:

sudo apt-get update
sudo apt-get install -y \
  libembree-dev \
  libenet-dev \
  libfreetype-dev \
  libpng-dev \
  zlib1g-dev \
  libgraphite2-dev \
  libharfbuzz-dev \
  libogg-dev \
  libtheora-dev \
  libvorbis-dev \
  libwebp-dev \
  libmbedtls-dev \
  libminiupnpc-dev \
  libpcre2-dev \
  libsdl3-dev \
  libzstd-dev \
  libsquish-dev \
  libicu-dev

Після встановлення всіх необхідних пакетів скористайтеся такою командою, щоб створити Godot:

scons platform=linuxbsd builtin_embree=no builtin_enet=no builtin_freetype=no builtin_graphite=no builtin_harfbuzz=no builtin_libogg=no builtin_libpng=no builtin_libtheora=no builtin_libvorbis=no builtin_libwebp=no builtin_mbedtls=no builtin_miniupnpc=no builtin_pcre2=no builtin_sdl=no builtin_zlib=no builtin_zstd=no

У стабільній версії Debian вам потрібно буде видалити builtin_embree=no, оскільки надана системою версія Embree надто стара, щоб працювати з останньою master гілкою Godot (для якої потрібен Embree 4).

Ви можете переглянути список усіх вбудованих бібліотек, які мають системні альтернативи, запустивши scons -h, а потім шукаючи параметри, що починаються з builtin_.

Попередження

При використанні системних бібліотек отриманий двійковий файл більше не переноситься між дистрибутивами Linux. Не використовуйте цей підхід для створення двійкових файлів, які ви збираєтеся розповсюдити іншим, якщо ви не створюєте пакет для дистрибутива Linux.