The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Разработчики из компании Google открыли код системы сборки Ninja

08.02.2011 11:12

Под лицензией Apache открыты исходные тексты проекта Ninja, созданного разработчиками из компании Google в процессе портирования web-браузера Chrome для Linux и Mac OS X. Ninja представляет собой упрощенный вариант программы make, оптимизированный для значительного ускорения процесса повторной сборки крупных проектов, после внесения незначительных изменений в код. Ninja не поддерживает сложные сценарии принятия решений и оперирует простейшими правилами для описания зависимостей между файлами собираемого проекта. Вопрос учета системных зависимостей выносятся на плечи внешних инструментов, таких как пакет autotools.

Изначально, прототип 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" вместо длинной командной строки.


  1. Главная ссылка к новости (http://neugierig.org/software/...)
  2. OpenNews: Google представила инструментарий разработчика ПО с открытым исходным кодом
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/29525-make
Ключевые слова: make, build, ninja, google
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (39) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, dimqua (ok), 12:11, 08/02/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Хм, странно что сразу не открыли.
     
  • 1.2, Аноним (-), 12:15, 08/02/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • –9 +/
    ничего странного, могли вообще не открывать - не обязаны
     
     
  • 2.11, dimqua (ok), 13:15, 08/02/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если уж решили открывать, то странно что не сделали этого сразу. Чего ждали интересно.
     
     
  • 3.29, QuAzI (ok), 18:54, 08/02/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ждали, когда оно маленько заработало и стабилизировалось. А то много вечно недовольных хомячков, которые сначала нагадят "то не так, это хочу эдак", а потом после того как всё исправлено ещё 5 лет помоями поливают то, что сами не осилили.
     
     
  • 4.32, dimqua (ok), 22:25, 08/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Если бы сабж был игрой какой-нибудь, тогда было бы понятно. Но вариант программы make это ведь не для хомячков, ну. :)
     

  • 1.4, Аноним (-), 12:17, 08/02/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно, на каком железе у них за 6 секунд собирается?
     
     
  • 2.6, Lain_13 (?), 12:31, 08/02/2011 [^] [^^] [^^^] [ответить]  
  • +7 +/
    За 6 секунд при изменении одного файла. В этом вся идея, как я понял. Т.е. сидишь ты, колупаешься с одним файликом. Тыц — пересобрал, запустил, погонял и колупаешься дальше. Представляешь каково оно минут 10 минут ждать пока весь проект пересоберётся ради проверки одного мелкого изменения? Тут даже минуту ждать невыносимо.
     
     
  • 3.8, paulus (ok), 12:47, 08/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    гентушники говорят, что хромиум собирается как опенофис (сам не проверял), так что ускорение данного процесса явно не лишнее :-)
     
     
  • 4.14, h31 (ok), 14:10, 08/02/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тут немного не то. В топике идет речь о времени, которое уходит на служебные операции. Сама по себе компиляция не успорится.
     
  • 4.19, anonix (?), 14:58, 08/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Сборка в дженту, арче, да вообще везде не изменится по скорости никак. Потому как собирается там всё равно весь пакет.
    Здесь речь о другом - изменили 1 строчку кода, этот кусок скомпилили и прилинковали к уже собранным остальным кускам. Естественно такая схема вообще возможна только в разработческой среде.
     
  • 4.24, User294 (ok), 17:43, 08/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > гентушники говорят, что хромиум собирается как опенофис (сам не проверял), так что
    > ускорение данного процесса явно не лишнее :-)

    Редкий гентушник что-то *меняет* в собираемых исходниках, так что реально мало какой гентушник сильно выиграет от этого. Всего лишь наблюдение.

     

  • 1.5, Aleksey (??), 12:19, 08/02/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Перешел с Scons на Waf (https://code.google.com/p/waf/) и крайне доволен. Особенно радует скорость на крупных проектах.
     
     
  • 2.16, cdome (ok), 14:37, 08/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    +1. Согласен,

    Причем у меня waf быстрее даже make работает

     
  • 2.25, Аноним (-), 17:49, 08/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    А мы не видим альтернативы cmake. В waf (в отличие от scons) даже о портабельности не думали - по сути это make только с более заумным синтаксисом. SCons уже полноценная система сборки, но с ещё более убогим и сложным синтаксисом, не делающая 'automagically' ничего, что делают даже autocrap и располагающая к писанию всего руками под кучей if'ов для разных систем. Только cmake позволяет огромный проект с кучей внешних зависимостей собрать на любой платформе (включая кросскомпиляцию) без единой платформенно-зависимой строчки в CMakeLists.txt.
     
     
  • 3.28, Aleksey (??), 18:18, 08/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Согласен, что waf еще не достаточно распространен, но из этого не следует, что он не портабельный. То, что для Cmake написано больше модулей не отрицаю, но расширять waf намного проще. Кроме того не нужно изучать еще один нигде не нужный корявый язык программирования. Не говоря уже о том, что waf можно включать в бандл с исходниками и не требовать для сборки установки правильной версии Cmake.
     
     
  • 4.30, Аноним (-), 20:30, 08/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Согласен, что waf еще не достаточно распространен, но из этого не следует, что он не портабельный

    Ещё? Никогда не будет, потому что маргинален. И не он не портабельный, а скрипты на нём. И не в смысле "запуститься", а в смысле "без танцев с бубном собрать проект".

    > То, что для Cmake написано больше модулей не отрицаю, но расширять waf намного проще.

    Написав кучу кода на питоне? Спасибо, в scons это уже проходили. Можно сразу к сборочным скриптам на shell вернуться, там хоть синтаксис вменяемый и менее многословный.

    В cmake добавить поддержку новой библиотеки - FIND_FILE + FIND_LIBRARY. Проще просто нельзя.

    > Кроме того не нужно изучать еще один нигде не нужный корявый язык программирования.

    Это вы про питон? Врёте, в cmake не нужен питон, с ним вообще программировать не нужно.

    > Не говоря уже о том, что waf можно включать в бандл с исходниками и не требовать для сборки установки правильной версии Cmake.

    Назад к autocrap'у? Нет, спасибо, bundled сборочная система это тупиковый путь.

     
     
  • 5.33, Alexey (??), 22:30, 08/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Во-первых, Python всяко лучше, чем тот недоязык который есть в cmake.
    Во-вторых, вы забыли упомянуть что cmake настолько сложно расширить, что, например, до сих пор не написано поддержки C# (а ведь он наиболее похож на C++). По сути cmake - это система для одного языка программирования. Если не дай бог вам потребуется поддержать что-то свое нестандартное, да еще и с поддержкой зависимостей, то придется очень сильно попотеть.
    В-третьих, в cmake как я понимаю до сих пор нет аналога "configure --help" для получения всех опций сборки?
     
     
  • 6.35, Аноним (-), 02:19, 09/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Во-первых, Python всяко лучше, чем тот недоязык который есть в cmake.

    Это недалёкий фанатизм. Система сборки должна иметь простой и понятный синтаксис, а не нагромождение ручной работы со словарями, склеиванием строк плюсами и определения функций и классов. Питон имеет отвратительный синтаксис в принципе, а применимость его здесь просто нулевая. У меня складывается впечатление, что фанатики питона готовы писать сборочную систему на голом питоне, только потому что на питоне. SCons и waf это чуть-чуть упрощают, но сборочными системами от этого не становятся.

    > Во-вторых, вы забыли упомянуть что cmake настолько сложно расширить, что, например, до сих пор не написано поддержки C# (а ведь он наиболее похож на C++).

    Вы забили упомянять что это ваши фантазии, а про похожесть C# и C++ вообще ближе к бреду. Понятия не имею как компилируется C#, но у нас произвольные генераторы добавляются одной строчкой, и проекты, состоящие из кода не нескольких языках с кучей swig'овских обёрток, Qt с его moc/uic/rcc, документацией и тестами собираются влёт.

    > По сути cmake - это система для одного языка программирования. Если не дай бог вам потребуется поддержать что-то свое нестандартное, да еще и с поддержкой зависимостей, то придется очень сильно попотеть.

    Интересная у вас рефлексия. Именно то что "поддержать что-то свое нестандартное, да еще и с поддержкой зависимостей" (плюс добавлю "с возможностью сборки на разных платформах без писания, по сути, отдельного скрипта под каждую платформу") кроме cmake нету.

    > В-третьих, в cmake как я понимаю до сих пор нет аналога "configure --help" для получения всех опций сборки?

    Всегда был. cmake -L[A]H, ccmake

     
     
  • 7.45, Yaro (?), 21:10, 12/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Согласен с вами,
    В cmake нет ничего для C# потому что C# и кросс-платформенность - взаимоисключающие пункты.
     

  • 1.7, LuckAs (ok), 12:39, 08/02/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Маньяки, им 10 секунд было много компилировать то, что они разрабатывают как минимум несколько дней.
     
     
  • 2.26, Одмин (?), 17:58, 08/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Эти несколько дней они сотни раз проект пересобирают. По крайней мере надеюсь что хром это не write-only проект :)
     

  • 1.9, Аноним (-), 12:55, 08/02/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    А про cmake они наверное не слышали.. Их Ninja только с -j1 собирать может :(
     
     
  • 2.10, Сергей (??), 12:58, 08/02/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    cmake пользуется make-ом
     
     
  • 3.23, Аноним (-), 17:35, 08/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Это отнюдь не исключает того факта что "Ninja только с -j1 собирать может"
    А CMake может использовать как сам make, так и многое другое:
    Borland Makefiles
    MSYS Makefiles
    MinGW Makefiles
    NMake Makefiles
    NMake Makefiles JOM
    Unix Makefiles
    Visual Studio 10
    Visual Studio 6
    Visual Studio 7
    Visual Studio 7 .NET 2003
    Visual Studio 8 2005
    Visual Studio 9 2008
    Watcom WMake

    Зачем лепить новый велосипед... Когда есть трушный cmake! :)

     
     
  • 4.27, Аноним (-), 18:08, 08/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    > NMake Makefiles JOM
    > Unix Makefiles
    > Visual Studio 10
    > Visual Studio 6
    > Visual Studio 7
    > Visual Studio 7 .NET 2003
    > Visual Studio 8 2005
    > Visual Studio 9 2008
    > Watcom WMake
    > Зачем лепить новый велосипед... Когда есть трушный cmake! :)

    Это не замена CMake. Это вместо make, возможно будет новый бекенд для CMake

     
  • 2.12, Аноним122333 (?), 13:15, 08/02/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    тогда к чему было это:

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

    ???

     

  • 1.13, Аноним (-), 13:23, 08/02/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Из README:

    Though the code is copyright Google, don't take that as an
    endorsement; I wrote this in my spare time for fun.

    Вот с этого надо было начать новость.

     
  • 1.15, sluge (ok), 14:28, 08/02/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ccache+distcc спасут гиганта мысли
     
     
  • 2.31, Аноним (-), 22:00, 08/02/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Читать и думать вообще не умеем? Когда изменяется один исходник нужно
    - скомпилировать этот исходник
    - перелинковать бинарники/библиотки в которые этот файл линкуется

    ccache тут не впёрся потому что файл таки надо пересобрать, а distcc потому что файл один и параллеить нечего.

    Суть новости в том что поделие под названием SCons чтобы понять что надо пересобрать этот один файл полчаса тупит своим питоном. Обычный make они не осилили, поэтому решено было написать свой костыль.

     
     
  • 3.37, Вова (?), 12:51, 09/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    И как часто случается, самые грамотные каменты от анонимов. Я вчера ровно на этом месте впал в эйфорию, начитавшись серебряных пуль в вышестоящих комментариях. Отокомментил по смыслу то же самое, что и вы, как обычно - по делу, без оффтопа, кратко и осмысленно. Но сервер, видимо, сбоит (фс сыпется?) каменты пропадают.
     

  • 1.34, Аноним (-), 23:34, 08/02/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > высокопроизводительному линкеру

    Что за производительный линкер? Не binutils/ld надеюсь?

     
  • 1.36, Аноним (-), 11:48, 09/02/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    На haskell отличная система сборки: ghc --make someModule.hs
    Дальше парсится код, находятся зависимости и вуаля -
    больше ничего делать не надо.
    Ничего похожего для .NET я не нашел - может плохо искал
    SCons по сравнению с этим смотрится блекло, нечего говорить про
    make-подобные системы
     
     
  • 2.38, Аноним (-), 14:11, 09/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Ну в песочнице из одного файла я так и для C могу сделать. Напомню, что в реальном мире файлов куча, лежат они в разных местах (особенно на разных системах) зависимости не всегда явно прописаны (dlopen), нужно всё равно линковаться с сишным кодом, выполнять тесты на пригодность и особенности окружения, поддерживать кросскомпиляцию, опции и ещё кучу всего.
     
     
  • 3.39, Аноним (-), 15:00, 09/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Для C такое и не сделаешь - обычно задача стоит собрать нечто из
    кучи разнородного содержимого.
    Но для управляемых языков отсутствие действительно удобных средств сборки странно.
     

  • 1.40, Ne01eX (??), 16:46, 09/02/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Так-то если столмановский мейк кастрировать, то он тоже будет шустро работать... :-\
     
     
  • 2.42, Andrey Mitrofanov (?), 18:50, 09/02/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тебе тож не отрезать, а даже прищемить -- ещё не так _забегаешь

     
     
  • 3.44, Ne01eX (??), 00:23, 11/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так и я про тоже =)
     

  • 1.41, Аноним (-), 18:33, 09/02/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А нехрен было все внешние либы тащить в проект, у них там в исходниках 5% хромиума и 95% сторонних компонентов, которые у нормальных людей ставятся с помощью пакетного менеджера. Устроили виндоус-стайл, сами себе создали проблему, а потом героически её решают, работа кипит, фигли.
     
     
  • 2.43, LuckAs (ok), 16:25, 10/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Думаю так оно и есть, пусть делают типа как Опера:
    - shared (работает с либами установленными в системе)
    - static (слинкованый с своими внутренними либами и работает с инсталятора)
    тогда видно разницу будет.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру