Компания Google открыла (http://neugierig.org/software/chromium/notes/2011/02/ninja.html) под лицензией Apache исходные тексты проекта Ninja (https://github.com/martine/ninja), созданного в процессе портирования web-браузера Chrome в Linux и Mac OS X. Ninja представляет собой (http://martine.github.com/ninja/manual.html) упрощенный вариант программы make, оптимизированный для значительного ускорения процесса сборки крупных проектов.
Изначально, прототип Chrome был создан только для Windows и разработчики для упрощения переноса на другие платформы попытались адаптировать для данной задачи систему Scons (http://www.scons.org/), но столкнулись с рядом трудностей. В частности, ценой простоты использования написанной на языке Python утилиты Scons была низкая производительность - на предсборочный анализ 30 тыс. файлов уходило примерно 40 секунд, а на пересборку бинарного файла после изменения всего одного файла с кодом уходило 8 минут. Не желая мириться с подобными задержками, подрывающи...URL: http://neugierig.org/software/chromium/notes/2011/02/ninja.html
Новость: http://www.opennet.dev/opennews/art.shtml?num=29525
Хм, странно что сразу не открыли.
ничего странного, могли вообще не открывать - не обязаны
Если уж решили открывать, то странно что не сделали этого сразу. Чего ждали интересно.
Ждали, когда оно маленько заработало и стабилизировалось. А то много вечно недовольных хомячков, которые сначала нагадят "то не так, это хочу эдак", а потом после того как всё исправлено ещё 5 лет помоями поливают то, что сами не осилили.
Если бы сабж был игрой какой-нибудь, тогда было бы понятно. Но вариант программы make это ведь не для хомячков, ну. :)
Интересно, на каком железе у них за 6 секунд собирается?
За 6 секунд при изменении одного файла. В этом вся идея, как я понял. Т.е. сидишь ты, колупаешься с одним файликом. Тыц — пересобрал, запустил, погонял и колупаешься дальше. Представляешь каково оно минут 10 минут ждать пока весь проект пересоберётся ради проверки одного мелкого изменения? Тут даже минуту ждать невыносимо.
гентушники говорят, что хромиум собирается как опенофис (сам не проверял), так что ускорение данного процесса явно не лишнее :-)
Тут немного не то. В топике идет речь о времени, которое уходит на служебные операции. Сама по себе компиляция не успорится.
Сборка в дженту, арче, да вообще везде не изменится по скорости никак. Потому как собирается там всё равно весь пакет.
Здесь речь о другом - изменили 1 строчку кода, этот кусок скомпилили и прилинковали к уже собранным остальным кускам. Естественно такая схема вообще возможна только в разработческой среде.
> гентушники говорят, что хромиум собирается как опенофис (сам не проверял), так что
> ускорение данного процесса явно не лишнее :-)Редкий гентушник что-то *меняет* в собираемых исходниках, так что реально мало какой гентушник сильно выиграет от этого. Всего лишь наблюдение.
Перешел с Scons на Waf (https://code.google.com/p/waf/) и крайне доволен. Особенно радует скорость на крупных проектах.
+1. Согласен,Причем у меня waf быстрее даже make работает
А мы не видим альтернативы cmake. В waf (в отличие от scons) даже о портабельности не думали - по сути это make только с более заумным синтаксисом. SCons уже полноценная система сборки, но с ещё более убогим и сложным синтаксисом, не делающая 'automagically' ничего, что делают даже autocrap и располагающая к писанию всего руками под кучей if'ов для разных систем. Только cmake позволяет огромный проект с кучей внешних зависимостей собрать на любой платформе (включая кросскомпиляцию) без единой платформенно-зависимой строчки в CMakeLists.txt.
Согласен, что waf еще не достаточно распространен, но из этого не следует, что он не портабельный. То, что для Cmake написано больше модулей не отрицаю, но расширять waf намного проще. Кроме того не нужно изучать еще один нигде не нужный корявый язык программирования. Не говоря уже о том, что waf можно включать в бандл с исходниками и не требовать для сборки установки правильной версии Cmake.
> Согласен, что waf еще не достаточно распространен, но из этого не следует, что он не портабельныйЕщё? Никогда не будет, потому что маргинален. И не он не портабельный, а скрипты на нём. И не в смысле "запуститься", а в смысле "без танцев с бубном собрать проект".
> То, что для Cmake написано больше модулей не отрицаю, но расширять waf намного проще.
Написав кучу кода на питоне? Спасибо, в scons это уже проходили. Можно сразу к сборочным скриптам на shell вернуться, там хоть синтаксис вменяемый и менее многословный.
В cmake добавить поддержку новой библиотеки - FIND_FILE + FIND_LIBRARY. Проще просто нельзя.
> Кроме того не нужно изучать еще один нигде не нужный корявый язык программирования.
Это вы про питон? Врёте, в cmake не нужен питон, с ним вообще программировать не нужно.
> Не говоря уже о том, что waf можно включать в бандл с исходниками и не требовать для сборки установки правильной версии Cmake.
Назад к autocrap'у? Нет, спасибо, bundled сборочная система это тупиковый путь.
Во-первых, Python всяко лучше, чем тот недоязык который есть в cmake.
Во-вторых, вы забыли упомянуть что cmake настолько сложно расширить, что, например, до сих пор не написано поддержки C# (а ведь он наиболее похож на C++). По сути cmake - это система для одного языка программирования. Если не дай бог вам потребуется поддержать что-то свое нестандартное, да еще и с поддержкой зависимостей, то придется очень сильно попотеть.
В-третьих, в cmake как я понимаю до сих пор нет аналога "configure --help" для получения всех опций сборки?
> Во-первых, 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
Согласен с вами,
В cmake нет ничего для C# потому что C# и кросс-платформенность - взаимоисключающие пункты.
Маньяки, им 10 секунд было много компилировать то, что они разрабатывают как минимум несколько дней.
Эти несколько дней они сотни раз проект пересобирают. По крайней мере надеюсь что хром это не write-only проект :)
> надеюсь-_-
А про cmake они наверное не слышали.. Их Ninja только с -j1 собирать может :(
cmake пользуется make-ом
Это отнюдь не исключает того факта что "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! :)
>[оверквотинг удален]
> 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
тогда к чему было это:>>>Буферизация вывода всех параллельно выполняемых команд, что позволило более точно ассоциировать ошибку с вызвавшей её командой, без смешивания с выводом от других процессов;<<<
???
Из README:Though the code is copyright Google, don't take that as an
endorsement; I wrote this in my spare time for fun.Вот с этого надо было начать новость.
ccache+distcc спасут гиганта мысли
Читать и думать вообще не умеем? Когда изменяется один исходник нужно
- скомпилировать этот исходник
- перелинковать бинарники/библиотки в которые этот файл линкуетсяccache тут не впёрся потому что файл таки надо пересобрать, а distcc потому что файл один и параллеить нечего.
Суть новости в том что поделие под названием SCons чтобы понять что надо пересобрать этот один файл полчаса тупит своим питоном. Обычный make они не осилили, поэтому решено было написать свой костыль.
И как часто случается, самые грамотные каменты от анонимов. Я вчера ровно на этом месте впал в эйфорию, начитавшись серебряных пуль в вышестоящих комментариях. Отокомментил по смыслу то же самое, что и вы, как обычно - по делу, без оффтопа, кратко и осмысленно. Но сервер, видимо, сбоит (фс сыпется?) каменты пропадают.
> высокопроизводительному линкеруЧто за производительный линкер? Не binutils/ld надеюсь?
На haskell отличная система сборки: ghc --make someModule.hs
Дальше парсится код, находятся зависимости и вуаля -
больше ничего делать не надо.
Ничего похожего для .NET я не нашел - может плохо искал
SCons по сравнению с этим смотрится блекло, нечего говорить про
make-подобные системы
Ну в песочнице из одного файла я так и для C могу сделать. Напомню, что в реальном мире файлов куча, лежат они в разных местах (особенно на разных системах) зависимости не всегда явно прописаны (dlopen), нужно всё равно линковаться с сишным кодом, выполнять тесты на пригодность и особенности окружения, поддерживать кросскомпиляцию, опции и ещё кучу всего.
Для C такое и не сделаешь - обычно задача стоит собрать нечто из
кучи разнородного содержимого.
Но для управляемых языков отсутствие действительно удобных средств сборки странно.
Так-то если столмановский мейк кастрировать, то он тоже будет шустро работать... :-\
Тебе тож не отрезать, а даже прищемить -- ещё не так _забегаешь
Ну так и я про тоже =)
А нехрен было все внешние либы тащить в проект, у них там в исходниках 5% хромиума и 95% сторонних компонентов, которые у нормальных людей ставятся с помощью пакетного менеджера. Устроили виндоус-стайл, сами себе создали проблему, а потом героически её решают, работа кипит, фигли.
Думаю так оно и есть, пусть делают типа как Опера:
- shared (работает с либами установленными в системе)
- static (слинкованый с своими внутренними либами и работает с инсталятора)
тогда видно разницу будет.