Увидел свет (http://blog.qt.digia.com/blog/2014/08/26/qbs-1-3-0-released/) релиз развиваемого проектом Qt сборочного инструментария qbs 1.3.0 (http://qt-project.org/wiki/qbs) (Qt Build Suite). Qbs использует упрощённый вариант языка QML для определения сценариев сборки проекта, что позволяет определять достаточно гибкие правила сборки, в которых могут подключаться внешние модули, использоваться функции на JavaScript и создаваться произвольные правила сборки. В отличие от qmake, qbs не привязан к Qt и изначально рассчитан на организацию сборки любых проектов.Используемый в qbs язык сценариев адаптирован для автоматизации генерации и разбора сценариев сборки интегрированными средами разработки. Кроме того, qbs не генерирует make-файлы, а сам без посредников, таких как утилита make, контролирует запуск компиляторов и компоновщиков, оптимизируя процесс сборки на основе детального графа всех зависимостей. Наличие изначальных данных о структуре и зависимостях в проекте позволяет эффективно распараллеливать выполнение операций в несколько потоков. Для крупных проектов, состоящих из большого числа файлов и поддиректорий, производительность повторной пересборки с использованием qbs может опережать make в разы - пересборка выполняется почти мгновенно и не заставляет разработчика тратить время на ожидание.
В новой версии (http://qt-project.org/doc/qbs-1.3/index.html) существенно улучшена интеграция с интегрированной средой разработки Qt Creator. Обеспечена возможность добавления/удаления файлов с исходным кодом в продукты qbs через штатное дерево проекта, по аналогии с работой с проектами на базе qmake. Перезагрузка проекта теперь осуществляется заметно быстрее и выполняется только при наличии реальной необходимости. Например, ускорение заметно в случаях, когда файл был изменён без нарушения семантики (добавлены пробелы). Из изменений в языке сценариев отмечается возможность установки разных профилей для определённых продуктов, например, для генерации разных исполняемых файлов для разных платформ. Проведена работа по снижению потребления памяти во время работы сборочного инструментария.
URL: http://blog.qt.digia.com/blog/2014/08/26/qbs-1-3-0-released/
Новость: http://www.opennet.me/opennews/art.shtml?num=40456
Использую qbs в течение двух лет, но не радуют постоянно вылязящие мелкие регрессии...например самая последняя версия у меня постоянно (!) собирает один и тот же файл при инкрементальной сборке. Все попытки сделать минимальный проект с глюком провалились. Откат на предыдущую версию конечно помог. Но нужно отдебажить все равно этот факт, чтобы в апстриме поправили...
щас соберу минусы, но всеравно не понимаю, чем не устраивает cmake. даже boost перетаскивают на cmake. лишняя сущность этот qbs.
У cmake отвратный синтаксис.
Замечательный там синтаксис. С одной стороны, он совершенно обычный (функция(аргументы), ${переменная}) вместо скобок он заставляет повторять условие в endif из-за чего читабельность повышается в разы.
JUST ADOPT CMAKE писали в комментариях к релизу qbs 0.3.0.Cmake - НЕ система сборки, а генератор makefile-ов. А некоторые вещи средствами make делать довольно геморно (например когда количество порождаемых продуктов динамично). cmake это обычно делает на этапе конфигурирования.
qbs не содержит в себе этапа генерации файлов. Он сам вызывает все инструменты.
А еще на этапе исследования систем сборки их синтаксис cmake тоже не устроил)
Я вообще тоже против "картинка xkcd про 15 стандартов", но qbs подкупил меня именно внятным и легким синтаксисом, который легко поддерживать.
>JavaScript
>внятным и легким синтаксисомне для всех js - это внятный синтаксис, хотя базовый правила описанные в документации просты и действительно понятны, в случае если их будет недостаточно придётся городить велосипед на js.
Cmake умеет генерировать не только Makefile. Есть к примеру выходной формат ninja, которая позволяет собирать проекты гораздо быстрее, хоть и не предназначена для чтения человеком.
> А некоторые вещи средствами make делать довольно геморно
> (например когда количество порождаемых продуктов динамично).Чуть конкретнее можно?
>Cmake - НЕ система сборки, а генератор makefile-ов.хм, вот почему все зацикливаются только на makefiles? cmake умеет генерировать не только их.
>например когда количество порождаемых продуктов динамичнониже уже просили привести пример, может стоит всё же продемонстрировать что скрывается за этой фразой.
cmake - жуткий монстр. Тонны исходников, собирается адски долго. Зато умеет разноцветно печатать. Наверное, autotools проще понять, хоть они и написаны на адской смеси Perl/m4.
Да бросьте. Qbs тоже не маленький. По сравнению с qmake например (он вообще собирается пока делаешь глоток чая).
На 4 ядрах у меня чуть ли не минуту собирается (фигня конечно, но легковесным бы не назвал).
Опять безграмотные высосанные из пальца придирки.
Какая вам разница сколько там исходников? Не вам в них разбираться. На самом-то деле всего в 4 раза больше чем в qbs, что полностью объяснимо в разы более богатой функциональностью.
Какая вам разница сколько он собирается? Не для каждого же проекта его собирать. На самом-то деле собирается он жалкие 3 минуты. Только QtCore от которого зависит qbs собирается уже столько же.
А вот по тому какие простые и понятные скрипты на нём пишутся, он уделывает и qbs и тем более autotools (перла в которых нет, позорище).
Да, действительно, Perl в autotools нет. За исключением того, что automake и autoconf - скрипты на Perl. </sarcasm>Насчёт сборки - да, действительно быстро собирается, проверил. Был неправ.
> ... За исключением того, что automake и autoconf - скрипты на Perl.$ file `which autoconf`
/usr/bin/autoconf: POSIX shell script, ASCII text executableПоздравляю, гражданин соврамши.
а как научить дизайнера писать в cmake? в qml он научился писать..
+ ещё 1 возможный камень в огород qbs я думаю сей товарищ просветит раз 2 года использует http://www.opennet.me/~%F7%CC%C1%C4%...для того чтобы что-то собрать нужно настоить toolchain в qbs
при условии что у нас 1 компилятор в системе - ничего плохого нет, просто 1 шаг перед использованием - предварительная настройка, но если нужно использовать более одного компилятора, изволь все их занести в настройки qbs и далее нужно указать что нам нужен именно этот toolchain, прекрасно если qbs запомнит этот выбор для каждой директории с проектом, если нет - это печально.
Не знаю, у меня как у разработчика, много тулчейнов на машине стоит, и я пока не жалуюсь на работу "qbs detect-toolchains" ...
Один раз настроив окружение, можно собирать много проектов из скриптов сразу же, не нужны предварительные ./configure.И да, если его использовать из Qt Creator то естественно все запомнится. Если запускаете с командной строки то да... здесь может быть дискомфорт))
>И да, если его использовать из Qt Creator то естественно все запомнится. Если запускаете >с командной строки то да... здесь может быть дискомфорт))для меня это -
>Не знаю, у меня как у разработчика, много тулчейнов на машине стоит, и я пока не жалуюсь >на работу "qbs detect-toolchains"
и он найдёт распакованный в хомяке или в /opt компилятор? что-то крайне сомнительно, думается всё равно руками надо будет добавлять.
очевидно, как и любой конфигурятор - если в PATH прописан, то найдет ;)
> очевидно, как и любой конфигурятор - если в PATH прописан, то найдет
> ;)это просто бессмысленно добавлять всё в PATH
а вообще как система сборки qbs иделано смотрится только вместе с IDE. под QtC все понятно, а под студию (оффтопик, да), можно использовать генератор проектов который qbs же и запускает.
https://bugreports.qt-project.org/browse/QBS-31
вот здесь я в комментах ссылку на патч добавил. можно пользоваться.
Да, до Gradle ему как раком до шанхая...
Посмотрел =) соглашусь с Вами! Возможности автоматического тестирования и сборки пакетов вряд ли когда еще появятся =(((
Вообще перейдя когда стал писать на Java постоянно подмечаю что практически все инструменты и Java технологи впереди планеты всей. Взять тот же Gradle, я ни то что бы аналога не видел для других языков я даже что то отдаленно напоменающее его по функционалу и возможностям не видел.
Всему виной энетрпрайзы с их требованиями и эвалюциями. Взять теже логгеры...
Так а вообще сравнение какое-нибудь gradle(+some plugin) vs qbs есть?
Ради интереса пробовал собрать им свой проект. Пришёл к выводу что с cmake он даже близко не стоял - попахивает scons'ятиной которая не сборочная система, а фреймворк для написания оных, в результате через скрипты представляют собой мешанину условий и вспомогательных функций для простейших вещей. Тут то же самое, но по возможностям она, похоже, ещё сильнее ограничена. В то же время CMake всё делает сам и скрипт представляет собой именно то что должен - перечисление опций, исходников, зависомостей и целей.