Опубликован (http://blog.qt.io/blog/2018/07/19/qbs-1-12-released/) релиз развиваемого проектом Qt сборочного инструментария Qbs 1.12 (http://qt-project.org/wiki/qbs) (Qt Build Suite), который заменит qmake в Qt 6. В отличие от qmake, Qbs не привязан к Qt и изначально рассчитан на организацию сборки любых проектов. Qbs использует упрощённый вариант языка QML для определения сценариев сборки проекта, что позволяет определять достаточно гибкие правила сборки, в которых могут подключаться внешние модули, использоваться функции на JavaScript и создаваться произвольные правила сборки.Используемый в Qbs язык сценариев адаптирован для автоматизации генерации и разбора сценариев сборки интегрированными средами разработки. Кроме того, Qbs не генерирует make-файлы, а сам, без посредников, таких как утилита make, контролирует запуск компиляторов и компоновщиков, оптимизируя процесс сборки на основе детального графа всех зависимостей. Наличие изначальных данных о структуре и зависимостях в проекте позволяет эффективно распараллеливать выполнение операций в несколько потоков. Для крупных проектов, состоящих из большого числа файлов и поддиректорий, производительность повторной пересборки с использованием Qbs может опережать make в разы - пересборка выполняется почти мгновенно и не заставляет разработчика тратить время на ожидание.
В новой версии:
- Для упрощения оформления библиотек для применения в сторонних проектах реализованы два новых модуля: Exporter.qbs (http://doc.qt.io/qbs/qml-qbsmodules-exporter-qbs.html) для создания qbs-модуля для итогового продукта (http://doc.qt.io/qbs/qml-qbslanguageitems-product.html) и Exporter.pkgconfig (http://doc.qt.io/qbs/qml-qbsmodules-exporter-pkgconfig.html) для генерации файла ".pc" с метаданными pkgconfig. Указанные файлы включают информацию, необходимую для сборки сторонних проектов с предоставляемой библиотекой (например, в случае применения Exporter.qbs для использования библиотеки в другом qbs-проекте достаточно определить зависимость 'Depends { name: "mylib" }');
- В утилиту qbs-config добавлен новый тип настроек - системные настройки, действующие для всех пользователей (например, пути поиска исполняемых файлов и библиотек). Для манипуляции системными настройками добавлена опция "--system", применение которой возможно только при наличии прав администратора;- Добавлен новый тип свойств varList для списков объектов;
- В расширении FileInfo представлены две новые функции suffix (https://doc.qt.io/qbs/jsextension-fileinfo.html#suffix) и completeSuffix (https://doc.qt.io/qbs/jsextension-fileinfo.html#completesuffix);- В блоке Rule свойство explicitlyDependsOn больше не заимствует зависимости из других зависимостей (для выполнения данной операции предложено отдельное свойство explicitlyDependsOnFromDependencies. Для исключения путаницы свойство excludedAuxiliaryInputs переименовано в excludedInputs;
- Свойства cLanguageVersion и cxxLanguageVersion преобразованы в массивы и могут включать более одного значения, что позволяет в разных модулях определять разные требования к версиям языка;- В блок AutotestRunner добавлено свойство auxiliaryInputs для проверки наличия дополнительных ресурсов, необходимых для запуска autotest;
- Во всех командах обеспечен вывод имени продукта для всех генерируемых объектов, что может быть полезно в больших проектах, в которых присутствует несколько продуктов, содержащих файлы с одинаковыми именами;- Добавлена возможность генерации сборочных файлов в формате Makefiles для проектов Qbs.
URL: http://blog.qt.io/blog/2018/07/19/qbs-1-12-released/
Новость: https://www.opennet.ru/opennews/art.shtml?num=48990
Юзаю qbs, нравится, особенно в сравнении с cmake, qmake и подобными
Документирован только вот хреново.
А я попробовал и в ужасе вернулся на замечательный cmake.
Это называется «ниасилил».
Нет, не обязательно. Я был и остаюсь Qbs-фаном (я стал его использовать в продакшене с версии 1.0.0), статьи на хабр писал для агитации. Но у Qbs остается много недостатков по сравнению с CMake.
Один из главных на мой взгляд - разработчики забивают на то что нужно пользователям.
Посмотрите сколько тикет висел на реализацию VS генератора после прохождения ревью. Три года.
Сколько висит тикет на реализацию XCode генератора? он до сих пор открыт.
Почитайте ченджлоги Qbs 1.12 и CMake 1.12
Отсутствие вменяемой совместимости как у CMake. (1-2 релиза и прощай, пересборка QtC возможна зачастую только ровно предыдущей версией его же (я о встроенной qbs поддержке)
Отсутствие коммьюнити, мейл лист достаточно тухлый (по крайней мере был год назад, сейчас я от него отписан)
Проект пилят полтора человека, не знаю почему Qt Company не выделяет больше ресурсов.Сама по себе идея и задумка хорошая, но очень сильно отставание от уходящего поезда CMake...
ninja предоставляет ничуть не хуже скорости инкрементных сборок. Одна беда - скорость конфигурирования самого cmake (которую обычно приплюсовывают ко времени для сравнения с qbs).
Если вам надо часто что-то переконфигурировать, а скрипты тяжелые, это беда-печаль. На моем проекте это около полуминуты.
>Я был и остаюсь Qbs-фаномВладимир, можете показать ваш проект который собирается Qbs-ом. Интересно посмотреть на реальный пример. Я сейчас использую cmake. Qbs меня в свое время заинтересовал, но по "игрушечным" примерам из документации я не понял он удобнее будет чем cmake, или нет.
> Но у Qbs остается много недостатков по сравнению с CMake.Мой любимый недостаток - сложность запуска произвольных команд. В Qbs для запуска парочки произвольных команд нужно написать код на JavaScript, который делает следующее:
1. Создает массив из аргументов команды.
2. Создает объект Command, куда передается имя команды и массив с аргументами.
3. Создает массив из объектов типа Command.
4. Возвращает массив с объектами типа Command для присваивания Rule.prepare.Я понимаю, это соответствует идеологии Qbs с Яваскриптом во все поля, но получается слишком навороченно и не очень-то читабельно.
add_custom_command в CMake смотрится гораздо проще и чище.
Навороченно - да, на счет читабельно там 50/50, в случае мало-мальски сложного скрипта CMake начинает отставать.
Когда прикручиваешь какой-то сраный def парсер или подобное, да, вымораживает.
Зато блин в cmake для некоторых кастомных таргетов приходится конфигурить вспомогательные скрипты, а в qbs о таком можно забыть.Ну и да, не для "произвольного" когда все-таки, никто не мешает файлы прочитать просто в проперти той же) я так какое-то автоконфигурирование делал безо всяких Probe-ов, они тогда сырые были еще, не слежу как у них сегодня ситуация.
ну и еще плюс к CMake - в нем просто ОХРЕНИТЕЛЬНАЯ стандартная библиотека. Написано скриптов поддержки фич на кучу разных платформ на все случаи жизни. Мне кажется в текущем виде CppModule.qbs очень плохо будет горизонтально масштабироваться.
Уже можно им QtC собрать?
qbs скрипты для QtC есть с версии 2.6, что ли. Так что ответ да - можно. Более того, я свой кастомный плагин только им и собираю, выходит намного быстрее, чем с qmakе собрать только одну цель.
> qbs скрипты для QtC есть с версии 2.6, что ли.Скрипты то есть, но говорят собрать ими QtC нельзя до сих пор.
Блин, ну раз нельзя, пойду удалю свою сборку тогда, и коллегам скажу чтобы не использовали мои бинарники...
В блоге кьюта как раз сообщают об обратном
> В блоге кьюта как раз сообщают об обратномНе знаю, у меня не собиралось и кютешники говорили, что не собирается. Это не разработчик ответил.
>В отличие от qmake, Qbs не привязан к QtВ каждой новости копипастят одно и то же. Автор похоже не в курсе, что Qbs требует qtbase и qtdeclarative. А вот qmake можно и без qt собрать. Было бы желание
Научили бы его качать модули из внешнего репозитория таким образом, чтобы он работал на манер cargo, цены бы ему не было. Да и вроде кажется, что это не так уж сложно сделать было бы, но почему-то нет такой задачи, что огорчает.
deb и rpm - по сути и есть репозитории для C/C++ проектов. Мультиплатформенный реп для С++ все равно неподъемная задача.Это для других языков самостоятельные мультиплатформенные репы - когда язык обеспечивает должную изоляцию от платформы.
Ага, а еще распределённую сборку туда впихнуть. И возможность собирать по SSH. И блокчейн.p.s. простите за яд, это все правда клёво, но к сожалению там разработчики не справляются и с реализацией того что и так минимум нужно (точнее справляюсь, но крайне со скрипом)
Уже сделали: https://nixos.org/nix/
А как у него с кроссплатформенностью?
В частности, можно ли собрать Android APK?
Не понимаю я пользователей этой штуки. Обратной совместимости толком нет, разработка живет в отдельной вселенной. Выше писали про необходимость городить на js банальные вещи.
Зачем вы пользуетесь этим?
Ни дай бог на это целиком перейдет Qt6... :-/