Изначально, прототип Chrome был создан только для Windows и разработчики для упрощения переноса на другие платформы попытались адаптировать для данной задачи систему Scons, но столкнулись с рядом трудностей. В частности, ценой простоты использования написанной на языке Python утилиты Scons была низкая производительность - на предсборочный анализ 30 тыс. файлов уходило примерно 40 секунд, а на пересборку бинарного файла после изменения всего одного файла с кодом тратилось до 8 минут. Не желая мириться с подобными задержками, подрывающими производительность труда, разработчики переписали правила сборки с использованием классических Make-сценариев, использование которых позволило сократить время сборки до 10-20 секунд, которые, благодаря высокопроизводительному линкеру, в основном уходили на предсборочный анализ.

Но и 10 секунд показалось разработчикам большим расточительством, что дало повод задуматься о дальнейшей оптимизации и провести анализ узких мест в стандартой утилите GNU Make. В итоге за несколько дней на языке С++ была написана утилита Ninja, концептуально очень похожая на Make, но избавленная от некоторых тяжеловесных возможностей, таких как правила-суффиксы, функции, встроенные правила, такие как поиск в RCS. Использование Ninja позволило свести время выполнения служебных операций в процессе пересборки Chrome до 1 секунды. Общее время пересборки после модификации одного файла было уменьшено до 6 секунд.

Дополнительно в Ninja была добавлена поддержка некоторых новых возможностей, например:

• Буферизация вывода всех параллельно выполняемых команд, что позволило более точно ассоциировать ошибку с вызвавшей её командой, без смешивания с выводом от других процессов;

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

• Процесс сборки может приводить к созданию сразу нескольких целевых файлов;

• Формирование целевого файла косвенно зависит от формирующей его командной строки, т.е. изменение опций компилятора приводит к пересборке соответствующих файлов;

• Директории для помещения результатов сборки создаются до выполнения связанных с ними правил;

• При выполнении правил могут использоваться краткие описания выполняемых команд, например, "CC foo.o" вместо длинной командной строки;

http://www.opennet.ru/opennews/art.shtml?num=29525