Представлен (http://blog.qt.io/blog/2017/12/07/qbs-1-10-released/) релиз развиваемого проектом Qt сборочного инструментария Qbs 1.10 (http://qt-project.org/wiki/qbs) (Qt Build Suite), который заменит qmake в Qt 6. В отличие от qmake, Qbs не привязан к Qt и изначально рассчитан на организацию сборки любых проектов. Qbs использует упрощённый вариант языка QML для определения сценариев сборки проекта, что позволяет определять достаточно гибкие правила сборки, в которых могут подключаться внешние модули, использоваться функции на JavaScript и создаваться произвольные правила сборки.Используемый в Qbs язык сценариев адаптирован для автоматизации генерации и разбора сценариев сборки интегрированными средами разработки. Кроме того, Qbs не генерирует make-файлы, а сам, без посредников, таких как утилита make, контролирует запуск компиляторов и компоновщиков, оптимизируя процесс сборки на основе детального графа всех зависимостей. Наличие изначальных данных о структуре и зависимостях в проекте позволяет эффективно распараллеливать выполнение операций в несколько потоков. Для крупных проектов, состоящих из большого числа файлов и поддиректорий, производительность повторной пересборки с использованием Qbs может опережать make в разы - пересборка выполняется почти мгновенно и не заставляет разработчика тратить время на ожидание.
В новой версии:
- Возможность динамического определения профилей, что полезно когда проект имеет заранее известные требования к среде сборки или целевой платформе;
- Более естественная организация работы с вложенными группами, учитывая префиксы. Если префикс не определён в группе, то его значение берётся из родительской группы;
- В модулях и файловых метках (FileTagger) появилась возможность установки уровней приоритета, которые могут выступать в роли механизма разрешения конфликтов при необходимости выбора между несколькими разными реализациями одного модуля, соответствующими заданным условиям, или несколькими файловыми метками, указывающими на один и тот же файл. Например, установка приоритетов может оказаться полезной при наличии нескольких вариантов модуля cpp и необходимости активации разных реализаций для разных платформ;- Для установки файловых меток на генерируемые ресурсы добавлено новое свойство fileTags, которое можно применять в группах с фильтром fileTagsFilter. Новое свойство позволяет прикреплять дополнительные элементы к списку тегов, созданных правилом из неподконтрольного модуля;
- Добавлена начальная поддержка платформы UWP (https://ru.wikipedia.org/wiki/%D0%A3%D0%... (Universal Windows Platform);
- Добавлена возможность использования команды run для запуска и развёртывания Android-приложений на внешних устройствах, а также запуска и развёртывания приложений iOS и tvOS в симуляторе;- Добавлена поддержка компилятора Qt Quick и утилиты qmlcachegen;
- Добавлен модуль vcs, предоставляющий информацию о репозитории (пока поддерживаются только Git и Subversion);- Добавлен модуль cpufeatures для абстрагирования флагов компилятора, связанных с возможностями CPU (например, поддержка инструкций SSE);
- В интерфейс командной строки добавлена команда list-products для вывода списка имён продуктов, доступных в проекте.
URL: http://blog.qt.io/blog/2017/12/07/qbs-1-10-released/
Новость: http://www.opennet.me/opennews/art.shtml?num=47708
Ура! Скоро шестокеды!
Ура! А то пятые уже почти работают.
2 года уже нормально работают. В kubuntu 16.04 LTS, по крайне мере.
Собранные из ebuild'ов полностью работают, как это для вас не странно.
ХЗ, у меня и из преобычнейших реп работают.... ЧЯДНТ?
- доктор, у меня болит нога, что посоветуете?
- ХЗ, у меня тоже есть нога, и она не болит... ЧЯДНТ?!
И вот поэтому я буду всем здоровым говорить, что у них тоже болит нога, а они глупые не верят.
- доктор, меня ест нога, ЧЯДНТ?!
- ХЗ, я узбек... RTFM!
Когда попытался пошутить, но "как-то не удалось".
>В отличие от qmake, Qbs не привязан к Qt и изначально рассчитан на организацию сборки любых проектовВот зачем эту мантру повторять? 1. qbs зависит от Qt; 2. qmake может собрать любой проект.
Догадываюсь, что к моменту полной стабилизации кодовой базы, они добавят урезанный движок QML прямо в сам проект. И можно будет его устанавливать на сервере без Qt-модулей.
Движок QML зависит от QtCore и QtGui. Никто в здравом уме не будет их тащить с собой. А так на сервере собирай хоть сейчас, ничто этому не мешает.
статическую линковку запретили уже?
Давно с венды слез?
1) Одним qbs-ом можно собрать проект под разные версии Кути
2) Одним qmake-ом ты можеш собрать только проект с одной конкретной версией Кути
> 1) Одним qbs-ом можно собрать проект под разные версии Кути
> 2) Одним qmake-ом ты можеш собрать только проект с одной конкретной версией
> КутиПро обратную совместимость не в курсе, конечно.
Зависит от JavaScript'а, QtQuick'а и Qt'а. Ну и зачем такое счастье? Тогда уж проще взять Gradle, тот что на Java. Он как минимум легковеснее и функциональнее.И да, QBS точно так же, как make, опирается на дату изменения файла, а не на его хеш/отпечаток. Поэтому наследует проблемы своего предшественника.
Нисколько не удивительно, что он не вылез из экосистемы Qt'а ни на йоту. Да и в самой экосистеме имеет шаткое положение -- год другой и можно будет выкидывать, как уже выкинули QtScript, QtWebkit.
Напоминаю, что Qt и хотя бы его примеры так до сих пор и не перевели на QBS, хотя планы были грандиозные.
Так к 6 же переведут.QtScript выкинули в пользу QtQuick.
QtWebKit выкинули из-за стагнации в апстриме.
На очереди QtWidgets?
Нет. Разработчики сказали что QtQuick предпочтителен в долгосрочной перспективе и все усилия будут направлены на его развитие, чтобы он по возможностям догнал и перегнал QtWidgets. В QtWidgets нельзя по быстрому добавить свистоперделки, появившиеся в Win8 и Android, поэтому решили его (и себя) не калечить и сделать что-то новое. Но программисты вполне могут использовать QtWidgets, который помечен как законченный (доделанный).
>>QtWebKit выкинули из-за стагнации в апстриме.QtWebKit вполне себе развивается, а ядро WebKit - тем более. Просто в Qt нет ресурсов чтобы поддерживать и QtWebKit и QWebEngine (а делают это одни и те же люди), поэтому QtWebKit был удалён.
>тот что на Java. Он как минимум легковеснееНа Java легковеснее? Видимо, Дуплик зависит от каких-то веществ.
To build qbs simply doqmake -r qbs.pro
make
Зачем этот бардак они опять плодят??? неужели трудно взять и юзать cmake и не парится по поводу привязки? Он более гибкий чем этот qmake и более функциональный. Так они еще один бред придумали.
Так они все к своему фрэймворку привязывают, чтобы к конкурентам не бежали. Некоторым нравятся комбайны все в одном. Нормальные тактические ходы.
Звучит примерно так: производитель комбайнов выпустил новый набор гаечных ключей, чтобы таким образом привязать фермеров к своему изделию и не дать им перейти к производителям ручных косилок и молотилок. Но по какой-то неведомой причине фермерам нравятся комбайны, а не ручные косилки/молотилки. Это заговор чистой воды.
производитель комбанов решил перейти со старых вендорлочных гаечных ключей, к которым привыкли, на новые вендорлочные гаечные ключи, к которым страдальцы старого вендорлока опять должны привыкать, а стандартные ключи производитель комбайнов не желает использовать, ибо вендорлок это деньги
Если ключей от газонокосилки не хватает чтобы починить комбайн, то виноват конечно комбайн. Ну а чтобы построить ракету тем более не нужно ничего нового придумывать, вполне должно хватить ключей от газонокосилки, иначе это будет злой вендорлок.
Удобная система сборки - это хорошо.
CMake, сколь бы ни был популярным, удобным не является.
Чего стоит только лиспоподобный внутренний язык. JS, что в QML, какой-никакой язык общего назначения.
А зачем в системе сборки нужен язык общего назначения?
А зачем в системе сборки нужен эзотерический язык, который придётся осваивать, вместо того чтобы быстро настроить сценарии сборки, используя привычную логику?
Это либо должна быть чрезвычайно простая унифицированная система, как pip/go get/cargo, либо нечто расширяемое, но с вменяемым и простым языком.
Да затем, что не всем привычна логика JS (или python, или что там ещё сейчас модно в сборочницы пихать), а изучить с нуля простенький DSL намного легче.
> а изучить с нуля простенький DSL намного легчеэто сначала так кажется. а когда тебе придется перелопачивать тонны г-кода на этом простеньком DSL при практически полном отстуствии средств разработки и отладки, то хочется взять и у*бать тому, кто это язычок породил на свет
> Это либо должна быть чрезвычайно простая унифицированная система, как pip/go get/cargo,И что из перечисленного является сборочной системой?
>CMake, сколь бы ни был популярным, удобным не является.Ты просто его не осилил. Он прост, как топор.
Оксюморон же
Хорошо что развивается, это в любом случае лучше чем makefile
Но если в целом - то зачем вообще нужны сценарии и правила сборки? Описание проекта должно быть ДЕКЛАРАТИВНЫМ, а не представлять собой еще один язык императивного прорграммирования. То есть - список файлов исходников, параметры проекта (начиная от имени и заканчивая опциями оптимизации и кодогенерации), список внешних библиотек... все это по сути своей декларативная информация, то есть json или xml бы тут подошел лучше чем любой язык программирования. Исключения в виде запуска внешних программ для обработки чего-либо в процессе сборки должны оформляться как декларативные ноды специального типа, в которых прописывается внешняя программа и ее аргументы.
Так в Qbs так и есть же. И декларативность, и даже json. И исключения в виде запуска внешних программ. Но запуск внешних програм реализован довольно неудобно, по мне так. Так что если у вас нестандартная процедура сборки, требующая запуска многих внешних программ - ИМХО лучше использовать что-то другое, например тот же CMake. А если сборка стандартная - то Qbs удобнее, декларативнее и красивее.
ну я с вами не соглашусь, я еще в пору qbs 0.6-0.7 сборку на паскале прикручивал. Не могу сказать что это сделать сложнее чем в cmake.
Так и не понял, чем им qmake не угодил. И кому этот qbs будет нужен в остальных проектах, при наличии и так не малого зоопарка.
+1. До сих пор им никто не пользуется. Если кто-то начинает новый проект, то это или cmake или qmake.