|
| |
| 2.11, dimqua (ok), 13:15, 08/02/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Если уж решили открывать, то странно что не сделали этого сразу. Чего ждали интересно.
| | |
| |
| 3.29, QuAzI (ok), 18:54, 08/02/2011 [^] [^^] [^^^] [ответить]
| +5 +/– |
 Ждали, когда оно маленько заработало и стабилизировалось. А то много вечно недовольных хомячков, которые сначала нагадят "то не так, это хочу эдак", а потом после того как всё исправлено ещё 5 лет помоями поливают то, что сами не осилили.
| | |
| |
| 4.32, dimqua (ok), 22:25, 08/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
Если бы сабж был игрой какой-нибудь, тогда было бы понятно. Но вариант программы make это ведь не для хомячков, ну. :)
| | |
|
|
|
| |
| 2.6, Lain_13 (?), 12:31, 08/02/2011 [^] [^^] [^^^] [ответить]
| +9 +/– |
 За 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 +/– |
Сборка в дженту, арче, да вообще везде не изменится по скорости никак. Потому как собирается там всё равно весь пакет.
Здесь речь о другом - изменили 1 строчку кода, этот кусок скомпилили и прилинковали к уже собранным остальным кускам. Естественно такая схема вообще возможна только в разработческой среде.
| | |
| 4.24, User294 (ok), 17:43, 08/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
 > гентушники говорят, что хромиум собирается как опенофис (сам не проверял), так что
> ускорение данного процесса явно не лишнее :-)
Редкий гентушник что-то *меняет* в собираемых исходниках, так что реально мало какой гентушник сильно выиграет от этого. Всего лишь наблюдение.
| | |
|
|
|
| |
| 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 [^] [^^] [^^^] [ответить]
| +1 +/– |
Во-первых, Python всяко лучше, чем тот недоязык который есть в cmake.
Во-вторых, вы забыли упомянуть что cmake настолько сложно расширить, что, например, до сих пор не написано поддержки C# (а ведь он наиболее похож на C++). По сути cmake - это система для одного языка программирования. Если не дай бог вам потребуется поддержать что-то свое нестандартное, да еще и с поддержкой зависимостей, то придется очень сильно попотеть.
В-третьих, в cmake как я понимаю до сих пор нет аналога "configure --help" для получения всех опций сборки?
| | |
| |
| 6.35, Аноним (-), 02:19, 09/02/2011 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Во-первых, 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 [^] [^^] [^^^] [ответить]
| –1 +/– |
Согласен с вами,
В 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 собирать может :(
| | |
| |
| |
| 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.
Вот с этого надо было начать новость.
| | |
| |
| 2.31, Аноним (-), 22:00, 08/02/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
Читать и думать вообще не умеем? Когда изменяется один исходник нужно
- скомпилировать этот исходник
- перелинковать бинарники/библиотки в которые этот файл линкуется
ccache тут не впёрся потому что файл таки надо пересобрать, а distcc потому что файл один и параллеить нечего.
Суть новости в том что поделие под названием SCons чтобы понять что надо пересобрать этот один файл полчаса тупит своим питоном. Обычный make они не осилили, поэтому решено было написать свой костыль.
| | |
| |
| 3.37, Вова (?), 12:51, 09/02/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
И как часто случается, самые грамотные каменты от анонимов. Я вчера ровно на этом месте впал в эйфорию, начитавшись серебряных пуль в вышестоящих комментариях. Отокомментил по смыслу то же самое, что и вы, как обычно - по делу, без оффтопа, кратко и осмысленно. Но сервер, видимо, сбоит (фс сыпется?) каменты пропадают.
| | |
|
|
| 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 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ну в песочнице из одного файла я так и для C могу сделать. Напомню, что в реальном мире файлов куча, лежат они в разных местах (особенно на разных системах) зависимости не всегда явно прописаны (dlopen), нужно всё равно линковаться с сишным кодом, выполнять тесты на пригодность и особенности окружения, поддерживать кросскомпиляцию, опции и ещё кучу всего.
| | |
| |
| 3.39, Аноним (-), 15:00, 09/02/2011 [^] [^^] [^^^] [ответить]
| –1 +/– |
Для C такое и не сделаешь - обычно задача стоит собрать нечто из
кучи разнородного содержимого.
Но для управляемых языков отсутствие действительно удобных средств сборки странно.
| | |
|
|
| 1.40, Ne01eX (??), 16:46, 09/02/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Так-то если столмановский мейк кастрировать, то он тоже будет шустро работать... :-\
| | |
| 1.41, Аноним (-), 18:33, 09/02/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
А нехрен было все внешние либы тащить в проект, у них там в исходниках 5% хромиума и 95% сторонних компонентов, которые у нормальных людей ставятся с помощью пакетного менеджера. Устроили виндоус-стайл, сами себе создали проблему, а потом героически её решают, работа кипит, фигли.
| | |
| |
| 2.43, LuckAs (ok), 16:25, 10/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
Думаю так оно и есть, пусть делают типа как Опера:
- shared (работает с либами установленными в системе)
- static (слинкованый с своими внутренними либами и работает с инсталятора)
тогда видно разницу будет.
| | |
|
|
