Ninja (система сборки)

Система сборки Ninja, была разработана с целью заменить устаревшие системы сборки, не рассчитанные на крупные проекты с большим количеством кода. Кодовая база таких проектов как браузер Google Chrome и операционная система Android, уже на то время (2007—2012) составляла несколько миллионов строк кода и более 40 тыс. вхождений. Первоначально разработчики использовали систему сборки SCons, основанную на Python, но по заверению Эвана Мартина, SCons оказался слишком медленным и отнимал около 40 секунд на один лишь только запуск, перед тем как начиналась сама сборка. После чего, была предпринята попытка перевода проектов на систему Make, но после проведения очередных тестов, оказалось — что Make, также отнимал около 10 секунд на запуск и (10—20) секунд на инкрементальную сборку. Помимо этого, Make и SCons зачастую вызывали различные проблемы с кроссплатформенной разработкой. Это не устраивало Эвана и сподвигло его к разработке новой системы сборки, не имеющей таких недостатков[7][8].

Впервые Эван Мартин сообщил о планах и причинах разработки Ninja, в своём блоге — 6 февраля 2011 года[9]. На следующий год (8 мая 2012), состоялся первой выпуск Ninja[1], версии 120508 и был размещён на GitHub репозитории[4].

В ходе разработки, система сборки Ninja, приобрела множество новых особенностей, увеличивших скорость сборки[10][11][12]. Из таких особенностей можно отметить:

• Сокращение многократного и частого использования системы ввода-вывода (вывод всегда буферизируется);
• Процесс сборки по умолчанию запускается в параллельном режиме (задействуются все ядра доступных процессоров);
• Улучшена инкрементальная сборка (что значительно ускорило сборку проектов с большим количеством файлов и их дальнейшую пересборку);
• Добавлена специальная поддержка для обнаружения дополнительных зависимостей во время сборки (что позволяет легко корректировать зависимости заголовочных файлов для кода Си и C++)
• Использован re2c — генератор быстрых и легко встраиваемых лексеров, использующийся в разных проектах с целью ускорения лексического анализа[13][14].

Сам Эван не рекомендует писать сборочные скрипты Ninja вручную, по той простой причине, что синтаксис скриптов Ninja остался подобен Make синтаксису. Скорее всего, это было сделано, ради упрощения перевода программ с Make на Ninja и в угоду скорости исполнения, так как Make имеет довольно простую синтаксическую структуру и подобен языку ассемблера. По этой причине, написание на нём скриптов человеком, может быть затруднительным, а чтение и анализ синтаксиса программами, остаются тривиальными. Вместо ручного написания, рекомендуется использовать Ninja в сочетании с более «умными» системами мета-сборки (GYP, CMake, Meson и т. п.), имеющими встроенный генератор файлов Ninja[3].

Примерный перевод раздела о философии из руководства Ninja.

Эван Мартин. «The Ninja build system manual: Philosophical overview»[15]:

Там, где другие системы сборки являются языками высокого уровня, Ninja стремится быть ассемблером.

Системы сборки работают медленно, когда им нужно принимать решения. Когда вы находитесь в цикле редактирование-компиляция, вы хотите, чтобы он был как можно быстрее — вы хотите, чтобы система сборки выполняла минимальную работу, необходимую для определения именно того, что необходимо немедленно собрать.

Ninja содержит минимальную функциональность, необходимую для описания произвольных графов зависимостей. Отсутствие их синтаксиса делает невозможным выражение сложных решений.

Оригинальный текст (англ.)[показатьскрыть]

Where other build systems are high-level languages, Ninja aims to be an assembler.

Build systems get slow when they need to make decisions. When you are in a edit-compile cycle you want it to be as fast as possible — you want the build system to do the minimum work necessary to figure out what needs to be built immediately.

Ninja contains the barest functionality necessary to describe arbitrary dependency graphs. Its lack of syntax makes it impossible to express complex decisions..

Далее, приведён пример базового «.ninja» файла, демонстрирующего основную часть синтаксиса[16].

cflags = -Wall

rule cc
  command = gcc $cflags -c $in -o $out

build foo.o: cc foo.c

Ninja по умолчанию запускает сборку в параллельном режиме и задействует все доступные ресурсы компьютера. При определённых условиях это может привести к таким критичным проблемам, как переполнение буфера памяти или к перегреву вычислительного устройства, что случается с термоинтерфейсами, неспособными отводить большие объёмы тепла. Вследствие чего повышается риск программных ошибок из-за перегрева процессора и в итоге, может привести к аварийному отключению устройства.

Ninja не выводит подробный лог о процессе сборки, в угоду скорости исполнения, что затрудняет анализ при сборке и кросскомпиляции таких сложных программ, как ядро операционной системы, компилятор и им подобных.

• Автоматизация сборки
• Make
• SCons
• CMake
• Meson
• Premake
• GYP

• Официальный сайт (англ.)
• Руководство (англ.)
• Репозиторий проекта (англ.)
• Часто задаваемые вопросы (англ.)
• Расчёты скорости (англ.)
• Список генераторов, создающих файлы сборки ninja (англ.)