1.3, Аноним (-), 22:25, 09/09/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
> Сборка проекта, в котором не были изменены файлы, занимает примерно 200мс
200мс если железок не менее 10к будет многовато на один файл.
| |
|
2.15, Аноним (-), 01:33, 10/09/2015 [^] [^^] [^^^] [ответить]
| +5 +/– |
> Зачем это если есть CMake?
Наверное гуглу надоело майнтайнить свою энтерпрайзятину единолично. Вот правда просчет вышел: для тех кто не гугл - среда сборки требующая ЯВЫ и нацеленная на энтерпрайзные мегабилды в инфраструктуре а-ля гугль не очень сильно требуется. Это как на карьерном самосвале за хлебушком в магазин ездить.
| |
2.36, freehck (ok), 12:34, 10/09/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
Система сборки -- это не инструментарий для сборки одного проекта.
В задачи сборочной системы обычно входит сборка всех компонент под требуемую ось (а это развёртывание chroot-окружения, установка туда всех сборочных зависимостей пакета и т.п.), пакетирование их, построение changelog-а и его последующая рассылка. Возможно, некоторый веб-интерфейс управления этой штукой.
Короче, Cmake и систему сборки не совсем корректно сравнивать.
| |
|
|
4.51, freehck (ok), 11:00, 11/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
> Судя по их FAQ - такая же система сборки как и cmake,
> но с упором на быструю пересборку больших проектов при малых изменениях.
Если это аналог cmake, то как они обеспечивают заявленную повторяемость сборки?
> В BUILD-файлах обязательно полностью определены все зависимости, на основе которых принимаются решения по пересборке компонентов после внесения изменений и распараллеливании процесса сборки. Все операции сборки являются инкрементальными и всегда приводят к идентичному результату в любых окружениях;
Тут, кстати, действительно не очень понятно. Я возможно ошибочно предполагаю, что компонент -- это git-репозиторий. Возможно, это какие-то внутренние структуры проекта в этом репозитории.
Если у кого время будет, посмотрите пожалуйста, отпишите, что и как.
А то если у них действительно аналог make, рулящий зависимостями, то я в упор не понимаю, что мешает делать, как рекомендуется в man make:
http://git.freehck.ru/cfrolov.git/blob/master/Makefile
(см. "compile and generate dependency info")
| |
|
|
|
|
2.16, Аноним (-), 01:35, 10/09/2015 [^] [^^] [^^^] [ответить]
| –2 +/– |
> Где JavaScript !?!?
А ты что, компилировать его научился? :)
| |
|
3.20, Аноним (-), 06:28, 10/09/2015 [^] [^^] [^^^] [ответить]
| –3 +/– |
уже не в состоянии внимательно прочитать даже заголовок новости? "...системы сборки..." (внимание на слово "сборки", дегенерат)
| |
|
4.21, Аноним (-), 07:46, 10/09/2015 [^] [^^] [^^^] [ответить]
| –3 +/– |
> уже не в состоянии внимательно прочитать даже заголовок новости? "...системы сборки..."
> (внимание на слово "сборки", дегенерат)
Вот я и спрашиваю - что вы в JS "собираете", о великий интеллектуал?
| |
|
5.27, Crazy Alex (ok), 09:03, 10/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
ну, вообще для веба сейчас много чего собирают - js-модули в один файл, css, спрайты... плюс всякие уродства вроде CoffeeScript.
| |
|
6.52, Аноним (-), 15:02, 11/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
> ну, вообще для веба сейчас много чего собирают - js-модули в один
> файл, css, спрайты... плюс всякие уродства вроде CoffeeScript.
Слушай, я недооценил яваскриптеров. Сначала поорать что скриптоязык, компилить не надо, epic win! Потом проcpaть в хлам все это преимущество, при этом получив два вагона проблем с оптимизацией и вообще производительностью.
А потом эти, с их брокколи, пробуют сделать какую-нибудь онлайн игру и начинается феерическая сага о том как они пробовали что-нибудь придумать насчет garbage collector и лагов от него, как они изгалялись с типизированными массивами, как костылии с asm.js, как они ударно зарулили те проблемы ... которых для начала быть вообще было не должно, если бы это делалось в здравом уме и твердой памяти.
| |
|
|
|
|
|
|
|
3.38, Mihail Zenkov (ok), 12:52, 10/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
> А уже есть системы сборки на х86 ассемблере?
Возможно есть у KolibriOS или подобных.
Для моих нужд вполне хватает make + pkg-config: есть почти во всех системах, весит - 232KB (make) + 32KB (pkgconf - тоже что и pkg-config, но не тянет glib).
| |
|
2.22, Аноним (-), 07:47, 10/09/2015 [^] [^^] [^^^] [ответить]
| +3 +/– |
> Описание интересное, но после "System Requirements: Java JDK 7 or later" интерес
> мгновенно угас.
Так это гугл. Им не проблема поднять десяток серверов для такой фигни как сборка проекта.
| |
|
3.32, виндотролль (ok), 11:17, 10/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
> Так это гугл. Им не проблема поднять десяток серверов для такой фигни
> как сборка проекта.
Это гугл. Им проблемно ждать 12 часов, пока соберется один проект. Потому они поднимают десяток^Wдесятки серверов и собирают вместо 12 часов 10 минут. И bazel это умеет.
| |
|
4.40, Mihail Zenkov (ok), 13:06, 10/09/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Это гугл. Им проблемно ждать 12 часов, пока соберется один проект.
А нечего такой bloatware писать - LFS на относительно старой машине (amd 4 x 3.3 GHz) за 35-40 минут, BLFS - 2-4 часа. Ядро собирается за 3 минуты.
> Потому
> они поднимают десяток^Wдесятки серверов и собирают вместо 12 часов 10 минут.
> И bazel это умеет.
Это как? Где эта возможность описана (я про сборку одного проекта на десятках серверов)?
| |
|
5.42, виндотролль (ok), 13:28, 10/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
> А нечего такой bloatware писать - LFS на относительно старой машине (amd
> 4 x 3.3 GHz) за 35-40 минут, BLFS - 2-4 часа.
> Ядро собирается за 3 минуты.
объем кода — сотни таких «ядер». Потому и долго. В гугле все всегда собирают из исходников. Бинарных репозиториев (в явном виде) у них нету. Есть кеш артефактов, такой себе волатайл репозиторий. Ну и много GWT кода, который собирается очень долго.
> Это как? Где эта возможность описана (я про сборку одного проекта на
> десятках серверов)?
Эта возможность есть в их blaze (bazel опенсорсят с него). Надеюсь, что это добавят в bazel. Иначе, конечно, профита от новой системы сборки немного.
| |
|
|
7.47, виндотролль (ok), 14:48, 10/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
http://bazel.io/docs/cpp.html
cc_library дает obj
cc_executable линкует то, что накомпилил cc_library.
Не совсем понимаю, в чем проблема здесь. Но я с языками, где требуется линковка не работаю. Потому могу не понимать очевидных вещей.
| |
|
|
|
|
|
|
|
2.18, guest (??), 04:35, 10/09/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
Да, вот хреновина.
Прямо карусель получается. белл пришол -
собирает, ричард пришол - собирает.
пришол империя мелкозла - собирает.
пришол империя добра - собирает
Куды же жуниору податься?
Свои идут - уря, уря.
Вот тебе и "уря" . Дождались, мать твою...
| |
|
3.24, Аноним (-), 07:47, 10/09/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Ещё непроснувшийся мозг прочёл что новая система сборки урановая...
Она жабистая, что не сильно лучше :)
| |
|
|
1.26, Ромашко (?), 08:21, 10/09/2015 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Очередная опенсурсная поделка от Гугла, выкинутая на помойк^Wоткрытый доступ без организации открытой разработки и коммьюнити. Как обычно, на голову "лучше и удобнее" всех конкурентов, но зато написано полностью биороботами корпорации добра. Эдакий местечковый NIH.
Следуя традициям жанра, через полгода-год никто в Гугле про этот продукт даже и не вспомнит, а "довольные" юзеры поделки дальше побегут дальше онанировать на "передовые" технологии. Кто хоть раз юзал всякие gyp'ы или пытался скачать-собрать-пропатчить хоомв-андроиды и прочее меня поймут.
| |
|
2.30, виндотролль (ok), 11:14, 10/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
> через полгода-год никто в Гугле про этот продукт даже и не вспомнит
вообще-то терабайты исходников в гугле собираются именно этой системой сборки.
| |
|
1.50, Аноним (-), 00:10, 11/09/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
В собственном велосипеде gyp обнаружили фаталный недостаток?
Обязательно надо было новый?
| |
|