Компания Google открыла код сборочного инструментария Bazel (http://bazel.io/), основанного на наработках, используемых для сборки большинства внутренних проектов компании. Bazel обеспечивает сборку проекта, запуская необходимые компиляторы и тесты, выполняя задачи, аналогичные таким системам, как Make, Ant, Gradle, Buck, Pants и Maven. Bazel позволяет собирать проекты на любых языках программирования и отличается сочетанием высокой скорости, надёжности и повторяемости процесса сборки. Код Bazel распространяется (https://github.com/google/bazel) под лицензией Apache.В отличие от Make и Ninja в Bazel применяется более высокоуровневый подход к построению правил сборки, при котором вместо определения привязки команд к собираемым файлам производится применения более абстрактных готовых блоков, таких как "сборка исполняемого файла на языке С++", "сборка библиотеки на C++" или "запуск теста для C++", а также определение целевых и сборочных платформ. Дополнительная функциональность реализуется через механизм подключения расширений.
Для достижения высокой скорости сборки в Bazel активно применяются техники кэширования и распараллеливания процесса сборки. Инструментарий также гарантирует повторяемость сборки, т.е. результат сборки проекта на машине разработчика будет полностью совпадать со сборкой на сторонних системах, таких как серверы непрерывной интеграции. Bazel отлично подходит для сборки очень больших проектов или проектов, содержащих код на нескольких языках программирования, требующих расширенного тестирования или собираемых для нескольких платформ.Особенности (http://bazel.io/docs/FAQ.html) Bazel:
- Возможность использования для сборки кода, написанного на разных языках программирования. Из коробки поддерживается Java, Objective-C и C++, но через систему расширений возможна поддержка произвольных языков;
- Высокоуровневый язык задания правил сборки. В текстовом файле BUILD компоненты проекта описываются как связка библиотек, исполняемых файлов и тестов, без детализации на уровне отдельных файлов и команд вызова компилятора;
- Использование единых инструментов и сборочных файлов для разных платформ и архитектур. Например, один файл сборки без изменений может применяться как для серверной системы, так и для мобильного устройства;
- Повторяемость сборки. В BUILD-файлах обязательно полностью определены все зависимости, на основе которых принимаются решения по пересборке компонентов после внесения изменений и распараллеливании процесса сборки. Все операции сборки являются инкрементальными и всегда приводят к идентичному результату в любых окружениях;
- Высокая масштабируемость. В Google Bazel применяется для сборки проектов, которые могут насчитывать сотни тысяч файлов. Сборка проекта, в котором не были изменены файлы, занимает примерно 200мс. Пересборка выполняется только для файлов, которые требуют пересборки. Тесты выполняются только если текущее состояние проекта может привести к изменению результата.
Пример (https://github.com/google/bazel/tree/f01b229f426e7466b1be3c4...) сборочного файла:
<font color="#461b7e">package(default_visibility = ["//visibility:public"])
cc_library(
name = "hello-lib",
srcs = ["hello-lib.cc"],
hdrs = ["hello-lib.h"],
)
cc_binary(
name = "hello-world",
srcs = ["hello-world.cc"],
deps = [":hello-lib"],
)
cc_test(
name = "hello-success_test",
srcs = ["hello-world.cc"],
deps = [":hello-lib"],
)</font>
URL: http://www.reddit.com/r/programming/comments/30508z/google_o.../
Новость: http://www.opennet.ru/opennews/art.shtml?num=41908
Если там Java в жестких зависимостях то ИМХО проекты на плюсах пользовать почти не будут :(
Да нафига им этот баян? У плюсовиков теперь есть qbs.
В qbs сложно добавить поддержку компилятора, про который он не знает? У меня тут с CMake траблы, ищу куда перекатиться.
я на scons перебежал
И как оно? подойдет ли для сложного Qt'го кроссплатформенного проекта, где и Андроид, и Шиндовс, и чего только не надо собирать.
> я на scons перебежалНашел на что перебежать. Головняк с питоном на половине платформ - гарантирован. Впрочем, питон головняк сам по себе из-за кучи несовместимостей.
Scons радует вменяемым скриптовым языком (то, что сделано в CMake, языком назвать трудно, в 21 веке такого быть не должно). Но он, как показала практика, не очень быстр для очень больших проектов. У нас есть большие проекты и на том, и на том. Увы, о scons сильно жалеем. Удивительно, но в огромных проектах на нём именно внутренняя логика сборки начинает съедать время, почти сопоставимое со сборкой. Постоянное перечитывание всего и вся до добра не доводит.Если проект небольшой или средний -- смело вперёд на scons. Если там многие десятки сложных зависимостей и добрая сотня мегабайт исходных текстов, не советую, всё проклянёте.
> Удивительно, но в огромных проектах на нём именно внутренняя логика сборки
> начинает съедать время,"Питон не тормозит!!!11111"
Питон-то причём? Тут проблемы реализации.
> У меня тут с CMake траблыа что за траблы? ман курить не пробовали? :)
> а что за траблы? ман курить не пробовали? :)Компилятор, требующий танцев с бубном даже без CMake. А ман... ну все мы знаем, какой у CMake хороший ман.
> Компилятор, требующий танцев с бубном даже без CMakeтогда проблема не в cmake ;)
> тогда проблема не в cmake ;)ды проблема-то может быть хоть где угодно...
...однако хороший сборочный инструмент возьмёт эту проблему на себя и решит её :-)
(а иначе зачем тогда вообще нужен сборочный инструментарий, если он не решает проблемы?)
А можно подробнее про проблемы с CMake?
Когда я с ним работал (версии 2.x):1. Уродский синтаксис языка. Отсутствие функций и выражений.
2. Отсутствие внятной документации.
3. Невозможность использовать в одном проекте несколько компиляторов одного и того же языка.
qbs не взлетит из-за завязки на qt. Сейчас есть только cmake.
Ну почему же только cmake? Для тонких ценителей и любителей в гамаках полноценно на лыжах трахаться (что не плохо вобщем-то) есть еще scons
> Для тонких ценителей и любителей в гамаках полноценно на лыжах трахаться есть еще sconsа для любителей потрахаться по-настоящему есть bjam.
qbs уже не взлетел. и вряд ли взлетит,к сожалению.
>Код Bazel, который написан на языках Java и C++Ну и нахрена было городить такую дикую смесь? Ну спасибо что хоть Go не обмазали...
а в чем проблема? реально не понимаю. работает - гугл тестил.
или место надо экономить? вроде нет
fixed: "а в чем проблема? реально не понимаю. тормозит - гугл тестил.
или место надо экономить? вроде нет"
Эклипсерам должно понравиться.
>>Код Bazel, который написан на языках Java и C++
> Ну и нахрена было городить такую дикую смесь?Корпорация добра наносит ответный удар по мс-бильду. Сокрушительный удар.
> Ну спасибо что хоть Go не обмазали...
"Мы ж не звери."
> Корпорация добра наносит ответный удар по мс-бильду. Сокрушительный удар.С таким же успехом можно сказать, что "наносит ответный удар по gcc". msbuild -- всего лишь эквивалент gcc для вантуза от MS. Он представляет собой набор компайлеров, компоновщик, несколько утилит и пару скриптов, устанавливающих переменные среды. Да, конечно же и хидеры
>> Ну спасибо что хоть Go не обмазали...
> "Мы ж не звери."С явой то в обязательных зависимостях? За кадром слышен конский топот плюсовиков, побежавших ставить себе 100 метров рантайма ради кaлa^W среды сборки.
Для билд фермы совсем не проблема поставить один раз рантайм.
А вот если вас это значимый блоккер, то сабж не под ваши нужды - только и всего.
> Для билд фермы совсем не проблема поставить один раз рантайм.Ну да, если некто корпораха размером с гугл - они это конечно поставят. Вот только 99.9% разработчиков такой инфраструктурой не обладают :)
> А вот если вас это значимый блоккер, то сабж не под ваши
> нужды - только и всего.Ну понятно - фиговина будет обладать популярностью сравнимой с IBMовскими майнфреймами, по поводу чего через 5-10 лет гугл пульнет очередной анонс про шатдаун проекта :)
Для проектов-гигантов совершенно неважно, нужно ли JRE. Если в проекте 100 МБ исходников, а в собранном виде он занимает гигабайты, всем будет абсолютно всё равно, ставить ли CMake или что-то там с JRE. Если учесть, что под ограниченные в ресурсах платформы всё равно всё кросс-компилируют, так это вообще никого не будет волновать.Просто понятно, что маленькие проектики -- не целевая аудитория этой штуки.
> Просто понятно, что маленькие проектики -- не целевая аудитория этой штуки.Ну вон линуксное ядро - какой проект? А для сборки минимум зависимостей. Была б ему нужна ява для сборки - у него програмеров было бы в разы меньше. Потому что половине бы проблевалсь еще до того как смогли это скомпилить.
И что? У нас тоже есть большущие проекты на CMake. Может, не ядро, но тоже очень большие. Живут неплохо. Против CMake я как будто ничего не говорил. Даже являюсь горячим сторонником его идеологии (генерация сборочных файлов). А почитать выше, так и вовсе хвалил его (хотя язык описания в CMake откровенно плох, это я Вам как человек, имеющий опыт создания парсеров, скажу).Потом, Вы искренне полагаете, что человеку, неспособному даже JRE поставить, есть что делать в ядре?
С ядром причина другая, его теоретически можно под хитрое что-то и не кросс-компилировать, а собрать ПРЯМО на железке. Если такая возможность хотя бы раз в сто лет, одному экзотическому пользователю на миллион, нужна, о JRE речи уже нет. Но есть масса проектов, больших и серьёзных, для которых вопрос о сборке на кофеварке или роутере не встанет никогда. Для них наличие JRE в зависимостях ни горячо, ни холодно.
Да пофиг, все равно через несколько лет, по традиции, закроет проект
Для Go хотя бы jvm не нужна
Да потому что с++ это трах на хадулях и пишут на нем только от безвыходности, попробуй налобать на нем что нибудь подобное gradle и развивать его и расширять с такой же скоростью, а не раз в 100500 лет по одной плюшке.
> и развивать его и расширять с такой же скоростью, а не
> раз в 100500 лет по одной плюшке.Лучше попробуй на яве написать игру с нормальной графикой. И чтоб не тормозило и не клинило на полчаса пока GC мусор собирает. И чтоб 100 метров рантайма бонусом качать не надо.
Лучше б на go написали вместо этих двух. На rust не рассчитываю, ибо NIH.
Rust еще не стабилизирован, поэтому (пока) никто не будет использовать его в продакшне.А еще на нем писать в 2 раза сложнее чем на С++. И дело тут даже не в слишком умных указателях, а в страшной стандартной библиотеке, страшной документации, отсутствии тулинга и очень неторопливом компиляторе.
> И дело тут даже не в слишком умных указателях, а в страшной стандартной библиотеке, страшной документации, отсутствии тулинга и очень неторопливом компиляторе.Ну с С++ понятно, а на rust-то почему сложно?
Синдром утёнка же.
> А еще на нем писать в 2 раза сложнее чем на С++.Да ладно, не сложнее чем на плюсах с темплейтами.
И чем это лучше Gradle?
Bazel Frog (c) Без вины виноватый
Растёт замена emerge.
Берите выше: это растёт новая замена средства размножения человеков.
Чё уж там мелочиться?
Боже мой. В линуксе острая нехватка систем сборки?
ну так, не хватает сборки от гугла ))
На движке гугл хром.
> Боже мой. В линуксе острая нехватка систем сборки?Нужно больше минералов, милорд!
Острая нехватка *вменяемых* систем сборки. GNU Make — штука хорошая, конечно, но явно не достаточная.
У меня есть пример достаточности:simplelp генерирует несколько файлов, причём новое содержимое файлов сравнивается со старым и запись происходит только при несовпадении. Make делает лишнюю работу даже без "-j".
Какие системы сборки тут могут помочь?
недостаточности, конечно
System Requirements
Supported platforms:
Ubuntu Linux
Mac OS XJava:
Java JDK 8 or laterОсновной язык программирования:
Java 94.9%
Ну, чего, очередная система сборки от хипстоты для хипстоты. И да, она завершает сборку за 200 миллисекунд. При условии что вы развернете парк серверов как у гугли ;]
makefile наше все!
Для мелочей однозначно, для KDE/Firefox/Libreoffice/Kernel уже какая-то совсем невообразимая портянка.
Исходники в гугль шлет?
Работал в гугле. Система крутая, подтверждаю. Правда, результирующий собранный артефакт не особо закастомайзишь, но гуглю это и не надо было, там стандартизированный жесткий формат отлично принимался везде где надо.
Особый кайф - это что сборка распараллелена на Клауда, не больше минуты на сборку гигантских проектов.
Базельский мир
Базельский комитет по банковскому надзору
Базель 1
Базель 2
Базель 3
Игра в БИСЕР - Базельский игрок - :) ага, теперь Google скрывать нечего...И что он вам откомпилирует по Базелю :) ?
Че-то гугель заметался: то gradle в андроидную сборку притянет, то bazel 'развивает'...
Как он резолвит зависимости типа include в C++?
Обычно хреновины такого рода имеют собственный препроцессор а-ля C++ (...). (поэтому использование неожиданного для таких хреновин компилятора может лажать в вычислении зависимостей).