Анонсирован (http://google-opensource.blogspot.ru/2015/09/building-build-...) Bazel 0.1.0 (http://bazel.io/), первый выпуск (https://github.com/bazelbuild/bazel/releases/tag/0.1.0) открытого варианта сборочного инструментария, используемого для сборки большинства внутренних проектов компании Google. Выпуск 0.1.0 позиционируется как бета-версия, поддерживающая сборку серверного и клиентского ПО на языках C++, Java, Python, Rust, Objective-C и Shell. Код Bazel распространяется (https://github.com/bazelbuild/bazel/) под лицензией Apache.
Bazel обеспечивает сборку проекта, запуская необходимые компиляторы и тесты, выполняя задачи, аналогичные таким системам, как Make, Ant, Gradle, Buck, Pants и Maven. Среди отличительных особенностей Bazel выделяются высокая скорость, надёжность и повторяемость процесса сборки. Для достижения высокой скорости сборки в Bazel активно применяются техники кэширования и распараллеливания процесса сборки. Инструментарий также гарантирует повторяемость сборки, т.е. результат сборки проекта на машине разработчика будет полностью совпадать со сборкой на сторонних системах, таких как серверы непрерывной интеграции.
Bazel изначально спроектирован для оптимальной сборки проектов Google, в том числе сборки очень больших проектов и проектов, содержащих код на нескольких языках программирования, требующих расширенного тестирования и собираемых для нескольких платформ. В отличие от Make и Ninja в Bazel применяется более высокоуровневый подход к построению правил сборки, при котором вместо определения привязки команд к собираемым файлам производится применения более абстрактных готовых блоков, таких как "сборка исполняемого файла на языке С++", "сборка библиотеки на C++" или "запуск теста для C++", а также определение целевых и сборочных платформ. Дополнительная функциональность реализуется через механизм подключения расширений.Особенности (http://bazel.io/faq.html) Bazel:
- Возможность использования для сборки кода, написанного на разных языках программирования. Из коробки поддерживается Java, Objective-C и C++, но через систему расширений возможна поддержка произвольных языков;
- Высокоуровневый язык задания правил сборки. В текстовом файле BUILD компоненты проекта описываются как связка библиотек, исполняемых файлов и тестов, без детализации на уровне отдельных файлов и команд вызова компилятора;
- Использование единых инструментов и сборочных файлов для разных платформ и архитектур. Например, один файл сборки без изменений может применяться как для серверной системы, так и для мобильного устройства;
- Повторяемость сборки. В BUILD-файлах обязательно полностью определены все зависимости, на основе которых принимаются решения по пересборке компонентов после внесения изменений и распараллеливании процесса сборки. Все операции сборки являются инкрементальными и всегда приводят к идентичному результату в любых окружениях;
- Высокая масштабируемость. В Google Bazel применяется для сборки проектов, которые могут насчитывать сотни тысяч файлов. Сборка проекта, в котором не были изменены файлы, занимает примерно 200мс. Пересборка выполняется только для файлов, которые требуют пересборки. Тесты выполняются только если текущее состояние проекта может привести к изменению результата.Из особенностей первого выпуск отмечается формирование бинарных сборок для Linux и OS X, возможность загрузки зависимостей из Maven Central, сборка и установка программ для Android, сборка и загрузки образов Docker, возможность предварительной загрузки и кэширования внешних зависимостей и режим изолированной сборки в Linux (Sandboxing). Из планов на первый стабильный релиз Bazel 1.0, который ожидается в мае 2016 года, отмечается (http://bazel.io/roadmap.html) реализация поддержки языка Go, система распределённого кэширования, сборка из репоизиториев Github, сборка приложений для iOS, интерфейс для интеграции с IDE и поддержка платформы Windows.
URL: http://google-opensource.blogspot.ru/2015/09/building-build-...
Новость: http://www.opennet.me/opennews/art.shtml?num=42940
Java? ждите следующих исков от Oracle на API (Java Runtime)!
американский суд уже выносил решение, что API не предмет IP :)
Это решение уже отменили. Суд будет длиться бесконееееечно.
С разморозкой.
> Сборка проекта, в котором не были изменены файлы, занимает примерно 200мс200мс если железок не менее 10к будет многовато на один файл.
Сборка проекта с 10к файлов будет занимать 200мс.
Зачем это если есть CMake?
> Зачем это если есть CMake?Наверное гуглу надоело майнтайнить свою энтерпрайзятину единолично. Вот правда просчет вышел: для тех кто не гугл - среда сборки требующая ЯВЫ и нацеленная на энтерпрайзные мегабилды в инфраструктуре а-ля гугль не очень сильно требуется. Это как на карьерном самосвале за хлебушком в магазин ездить.
Система сборки -- это не инструментарий для сборки одного проекта.В задачи сборочной системы обычно входит сборка всех компонент под требуемую ось (а это развёртывание chroot-окружения, установка туда всех сборочных зависимостей пакета и т.п.), пакетирование их, построение changelog-а и его последующая рассылка. Возможно, некоторый веб-интерфейс управления этой штукой.
Короче, Cmake и систему сборки не совсем корректно сравнивать.
Судя по их FAQ - такая же система сборки как и cmake, но с упором на быструю пересборку больших проектов при малых изменениях.Непохоже что бы она могла сама автоматом притянуть Qt нужной версии, собрать его, прилинковать к при сборке и аккуратно все в пакет завернуть.
Пример для c++ https://github.com/bazelbuild/bazel/blob/master/examples/cpp...
Пример для d https://github.com/bazelbuild/bazel/blob/master/examples/d/h...Для обоих случаев имена зависимых файлов указываются явно.
> Судя по их FAQ - такая же система сборки как и cmake,
> но с упором на быструю пересборку больших проектов при малых изменениях.Если это аналог cmake, то как они обеспечивают заявленную повторяемость сборки?
> В BUILD-файлах обязательно полностью определены все зависимости, на основе которых принимаются решения по пересборке компонентов после внесения изменений и распараллеливании процесса сборки. Все операции сборки являются инкрементальными и всегда приводят к идентичному результату в любых окружениях;
Тут, кстати, действительно не очень понятно. Я возможно ошибочно предполагаю, что компонент -- это git-репозиторий. Возможно, это какие-то внутренние структуры проекта в этом репозитории.
Если у кого время будет, посмотрите пожалуйста, отпишите, что и как.
А то если у них действительно аналог make, рулящий зависимостями, то я в упор не понимаю, что мешает делать, как рекомендуется в man make:
http://git.freehck.ru/cfrolov.git/blob/master/Makefile
(см. "compile and generate dependency info")
Про Apple то зачем затёрли?
Где JavaScript !?!?
http://bazel.io/faq.html
> Bazel tries to minimize expensive compilation steps. If you are only using interpreted languages directly, such as JavaScript or Python, Bazel will likely not interest you.
> Где JavaScript !?!?А ты что, компилировать его научился? :)
уже не в состоянии внимательно прочитать даже заголовок новости? "...системы сборки..." (внимание на слово "сборки", дегенерат)
> уже не в состоянии внимательно прочитать даже заголовок новости? "...системы сборки..."
> (внимание на слово "сборки", дегенерат)Вот я и спрашиваю - что вы в JS "собираете", о великий интеллектуал?
ну, вообще для веба сейчас много чего собирают - js-модули в один файл, css, спрайты... плюс всякие уродства вроде CoffeeScript.
> ну, вообще для веба сейчас много чего собирают - js-модули в один
> файл, css, спрайты... плюс всякие уродства вроде CoffeeScript.Слушай, я недооценил яваскриптеров. Сначала поорать что скриптоязык, компилить не надо, epic win! Потом проcpaть в хлам все это преимущество, при этом получив два вагона проблем с оптимизацией и вообще производительностью.
А потом эти, с их брокколи, пробуют сделать какую-нибудь онлайн игру и начинается феерическая сага о том как они пробовали что-нибудь придумать насчет garbage collector и лагов от него, как они изгалялись с типизированными массивами, как костылии с asm.js, как они ударно зарулили те проблемы ... которых для начала быть вообще было не должно, если бы это делалось в здравом уме и твердой памяти.
Вот список только популярных систем сборок для javascript (а есть еще всякие самописные и непопулярные)http://gruntjs.com
http://coffeescript.org/documentation/docs/cake.html
http://gulpjs.com
https://github.com/broccolijs/broccoli
Описание интересное, но после "System Requirements: Java JDK 7 or later" интерес мгновенно угас.
А уже есть системы сборки на х86 ассемблере?
> А уже есть системы сборки на х86 ассемблере?Возможно есть у KolibriOS или подобных.
Для моих нужд вполне хватает make + pkg-config: есть почти во всех системах, весит - 232KB (make) + 32KB (pkgconf - тоже что и pkg-config, но не тянет glib).
> Описание интересное, но после "System Requirements: Java JDK 7 or later" интерес
> мгновенно угас.Так это гугл. Им не проблема поднять десяток серверов для такой фигни как сборка проекта.
> Так это гугл. Им не проблема поднять десяток серверов для такой фигни
> как сборка проекта.Это гугл. Им проблемно ждать 12 часов, пока соберется один проект. Потому они поднимают десяток^Wдесятки серверов и собирают вместо 12 часов 10 минут. И bazel это умеет.
> Это гугл. Им проблемно ждать 12 часов, пока соберется один проект.А нечего такой bloatware писать - LFS на относительно старой машине (amd 4 x 3.3 GHz) за 35-40 минут, BLFS - 2-4 часа. Ядро собирается за 3 минуты.
> Потому
> они поднимают десяток^Wдесятки серверов и собирают вместо 12 часов 10 минут.
> И bazel это умеет.Это как? Где эта возможность описана (я про сборку одного проекта на десятках серверов)?
> А нечего такой bloatware писать - LFS на относительно старой машине (amd
> 4 x 3.3 GHz) за 35-40 минут, BLFS - 2-4 часа.
> Ядро собирается за 3 минуты.объем кода — сотни таких «ядер». Потому и долго. В гугле все всегда собирают из исходников. Бинарных репозиториев (в явном виде) у них нету. Есть кеш артефактов, такой себе волатайл репозиторий. Ну и много GWT кода, который собирается очень долго.
> Это как? Где эта возможность описана (я про сборку одного проекта на
> десятках серверов)?Эта возможность есть в их blaze (bazel опенсорсят с него). Надеюсь, что это добавят в bazel. Иначе, конечно, профита от новой системы сборки немного.
https://news.ycombinator.com/item?id=9256844И еще здесь есть намек, что распределенные билды могут появиться в bazel
https://gradle.org/gradle-team-perspective-on-bazel/
Там у них в faq есть ссылка на цикл статей: http://google-engtools.blogspot.com/2011/09/build-in-cloud-d...Там подробно рассказывается как они организуют доступ серверов к исходникам и возврат сообщений сборки. Но я так и не понял - каким образом происходит запуск gcc на серверах и где происходит линковка? Как они с LTO справляются тем более не понятно.
http://bazel.io/docs/cpp.htmlcc_library дает obj
cc_executable линкует то, что накомпилил cc_library.Не совсем понимаю, в чем проблема здесь. Но я с языками, где требуется линковка не работаю. Потому могу не понимать очевидных вещей.
Непонятно как это все работает. Откуда берется gcc: с сервера или локальной машины? Заявлена повторяемость сборки, а разные версии gcc, да еще и в разном окружении, дадут разный результат. Кто и как запускает gcc на сервере? С LTO еще все более не понятно - ведь такой тип линковки не поддается параллельному исполнению и требует огромного количества памяти.
Все окружение — в облаке. Сорцы — тоже в облаке. Даже те, которые изменяются, тоже в облаке. Локально (возможно) генерируется только граф задач, исполнение всех задач и билд всех артефактов — в облаке. Если что-то не параллелится, значит оно не параллелится, но запускается все-равно на машине в облаке.
Ура, новая система сборки.
Да, вот хреновина.
Прямо карусель получается. белл пришол -
собирает, ричард пришол - собирает.
пришол империя мелкозла - собирает.
пришол империя добра - собирает
Куды же жуниору податься?
Свои идут - уря, уря.
Вот тебе и "уря" . Дождались, мать твою...
>Ура, новая система сборки.Ещё непроснувшийся мозг прочёл что новая система сборки урановая...
> Ещё непроснувшийся мозг прочёл что новая система сборки урановая...Она жабистая, что не сильно лучше :)
из урана хотя бы можно делать ломы. и топить их в ртути.
man "бронебойный подкалиберный", товарищ майор
Очередная опенсурсная поделка от Гугла, выкинутая на помойк^Wоткрытый доступ без организации открытой разработки и коммьюнити. Как обычно, на голову "лучше и удобнее" всех конкурентов, но зато написано полностью биороботами корпорации добра. Эдакий местечковый NIH.Следуя традициям жанра, через полгода-год никто в Гугле про этот продукт даже и не вспомнит, а "довольные" юзеры поделки дальше побегут дальше онанировать на "передовые" технологии. Кто хоть раз юзал всякие gyp'ы или пытался скачать-собрать-пропатчить хоомв-андроиды и прочее меня поймут.
Вам то что?
> через полгода-год никто в Гугле про этот продукт даже и не вспомнитвообще-то терабайты исходников в гугле собираются именно этой системой сборки.
А почему тогда версия только 0.1?
они опенсорсят свою систему сборки по частям
http://bazel.io/docs/install.html
- работает на устаревшем OpenJDK 7.
опять ты со своим страшным bsdm
iZEN
- онанирует на устаревшую операционку.
Зеня, завидуешь умственно отсталым?
В собственном велосипеде gyp обнаружили фаталный недостаток?
Обязательно надо было новый?