Компания Qt Company опубликовала (https://blog.qt.io/blog/2019/04/18/qbs-1-13-released/) сборочный инструментарий Qbs 1.13 (http://qt-project.org/wiki/qbs) (Qt Build Suite). Это последний выпуск Qbs, формируемый компанией Qt Company. Напомним, что ранее было принято (https://www.opennet.me/opennews/art.shtml?num=49519) решение о прекращении разработки Qbs. Qbs развивался как замена qmake, но в конечном счёте было решено использовать CMake в качестве основной сборочной системы для Qt в долгосрочной перспективе.
В ближайшее время ожидается создание независимого проекта по продолжению разработки Qbs силами сообщества, судьба которого будет зависеть от интереса к рассматриваемой системе сборки со стороны независимых разработчиков. Qt Company прекращает работу над Qbs из-за необходимости дополнительных инвестиций и больших затрат на продвижение Qbs.
Напомним, что для сборки Qbs в качестве зависимости требуется Qt, хотя сам Qbs рассчитан на организацию сборки любых проектов. Qbs использует упрощённый вариант языка QML для определения сценариев сборки проекта, что позволяет определять достаточно гибкие правила сборки, в которых могут подключаться внешние модули, использоваться функции на JavaScript и создаваться произвольные правила сборки.
Qbs не генерирует make-файлы и самостоятельно контролирует запуск компиляторов и компоновщиков, оптимизируя процесс сборки на основе детального графа всех зависимостей. Наличие изначальных данных о структуре и зависимостях в проекте позволяет эффективно распараллеливать выполнение операций в несколько потоков.
Основные новшества Qbs 1.13:
- Добавлена возможность использования в проектах модулей pkg-config с применением того же механизма обработки зависимостей, что применяется для модулей Qbs. Например, при наличии в системе пакета для сборки OpenSSL на базе pkg-config для его использоваия в проекте Qbs достаточно добавить 'Depends { name: "openssl" }';- Реализовано автоматическое определение доступных модулей Qt. Разработчикам больше не нужно создавать профиль с путями к модулям при помощи команды setup-qt, все указанные в зависимостях модули Qt будут настроены автоматически;
- Добавлены средства для контроля за числом параллельно запускаемых сборочных задач на уровне отдельных команд. Например, при выполнении связывания создаётся большая нагрузка на ввод/выводи и потребляется значительный объём ОЗУ, поэтому компоновщик требует иных настроек запуска, отличных от компилятора. Раздельные настройки теперь можно задать при помощи команды "qbs --job-limits linker:2,compiler:8";
- Внесены изменения в язык сценариев. Правила теперь могут определяться без указания файла-заглушки для вывода, а в начале файлов проектов не обязательно использовать директиву "import qbs". В элементы Application, DynamicLibrary и StaticLibrary добавлены новые свойства install и installDir для более удобной установки исполняемых файлов;- Добавлена поддержка рекурсивного сканирования скриптов компоновщика
GNU linker;
- Для языка C++ реализовано свойство cpp.linkerVariant для принудительного использования компоновщиков ld.gold, ld.bfd или lld;
- Для Qt представлено свойство Qt.core.enableBigResources для создания крупных ресурсов Qt- Вместо устаревшего элемента AndroidApk предложено использовать общий тип Application;
- Добавлен модуль для создания тестов на базе autotest;
- Добавлен модуль texttemplate с возможностями, похожими на QMAKE_SUBSTITUTES в qmake;- Добавлена начальная поддержка формата Protocol Buffers для C++ и Objective-C.
URL: https://blog.qt.io/blog/2019/04/18/qbs-1-13-released/
Новость: https://www.opennet.me/opennews/art.shtml?num=50535
Если бы он не зависел от Qt, у него был бы шанс, ИМХО (ничего не имею против Qt, но это слишком жирная зависимость для системы сборки).
NIH-наркоманы, как показывает практика, ни перед чем не останавливаются. Некоторые системы сборки даже Java тянут за собой, хотя вроде как к языку сами по себе не привязаны.
Так это отлично, раз здравый смысл взял верх. Редко такое бывает.
Чем он лучше cmake?
qml
то, что они решлили перейти на cmake, как бы намекает...
Они решили перейти на cmake, т.к. он более популярен. Допустим, php очень популярен: о чем это как бы намекает?
> о чем это как бы намекает"в мире есть 17 миллионов мух, которые едят дерьмо". Ну и что?
Это не мухи, а гвидобейсикокодеры. И дерьмо они столько едят, сколько производят.
Ты не путай похапе с гвидобейсиком!
> Они решили перейти на cmake, т.к. он более популярен. Допустим, php очень
> популярен: о чем это как бы намекает?это другой случай. тут есть уже работающая технология и ее поменяли.
а я ответил на вопрос человека "чем он лучше cmake". с него ушли. если бы был намного лучше, то остались бы на нем, вот и вся логика.
например без b2 наверное было бы трудно под столько компиляторов и платформ собирать, так что замена его на cmake вызывет некоторые трудности.
Что намекает? Что в Qt работают балаболы, которые годами говорили общественности, что qbs - это default build system in Qt6, а в итоге оказалось, что над qbs все эти годы в свободное от работы время работало пара человек? Да, это намекает. Те, кто следил за всей этой кухней и что она готовила прекрасно в курсе, что в Qt всё очень сильно не в порядке. Это стало понятно ещё пару лет назад, когда они додумались передаваемый в qdebug unicode выводить в виде hex-символов.
Действительно, лучше бы не прислушивались к сообществу и не смотрели бы на реальный мир, продвигая заведомо мертвую технологию.
По мне так команда кута тем и хорошая, что они принимают действительно взвешенные решения.
И да, с Qt по прежнему все отлично.
Как хорошо отвечать на пост, даже не читая его и не вдумываясь, что там написано, верно?
А с чего ты взял, её именно разрабы Qt пилили? И да, минимальный boostrap они тоже не осилили, точнее даже вообще не думали о его наличии.
Это не все ховшества. Там забыли упомянуть о том, что добавлена поддержка тулчейнов для baremetal, таких как IAR && KEIL (начиная с 1.13). Плюс, в > 1.13 добавлен тулчейн SDCC. Кроме того, в QtC > 4.9 в плагине baremetal также появилась возможность создавать комплекты для IAR && KEIL && SDCC и компилять проекты. Пока что это работает с архитектурами ARM, AVR и MCS51 (8051). Естественно, все это "экспериментальные" фичи и могут содержать баги. :)
> Чем он лучше cmake?Тем, что все работает из "коробки". Попробуй ка на CMake заюзать baremetal компиляторы также просто как с QBS && QtC. А я посмотрю.
Там нужно что-то более сложное, чем обычный toolchain-файл?
Ну нарисуй мне тулчейн файл для KEIL... Вбрасывать и я могу...В таком случае можно вообще не использовать CMake, а создать тупо *.bat файл и билдить что угодно и нафик тогда CMake вообще уперся.
Весь цимус здесь в удобстве разработки и интеграции с IDE, в данном случае с QtC. Здесь QtC тебе подсветит все макросы компилятора, инклуды, распарсит вывод текущего специфичного компилятора.
PS: Да и никто не заставляет тебя пользоваться QBS (я, вот, к примеру, не использую CMake), он найдет свое применение в любом случае, независимо от того, отказалась ли от него Qt Company или нет. Да и тема тут не о CMake, а о QBS...
> он найдет свое применение в любом случаеврядли
UPD: Также в QBS > 1.13 добавлены примеры для ARM (stm32) и AVR... В процессе добавление примера для MCS51 (естественно, юзаются GCC, IAR, KEIL, и будет юзаться SDCC).
UPD2: Также в процессе "запила" и генератор проектов для IAR из QBS. Пока что в отдельной репе: https://github.com/denis-shienkov/qbs/tree/iar-gen/src/plugi... (там вроде уже генерятся проекты для ARM, AVR, MCS51, но у меня пока нет времени чтоб это до-проверить). Если кому интересно - просьба потыкать. :) У меня пока все.
>Мы запилили некому ненужный костыль, который потом просто выкинули, вместо того, чтобы потратить эти человекочасы на вылов сегфолтов в библиотеке Qt и наконец-то стабилизировать плазму.Ясно.
Плазма это часть KDE, разработчикам Qt она вообще не уперлась
ну не запускать же эту старперскую configure, в самом деле?тем более в Б-жественной Десяточке, под которой и сидят все наши разработчики?
У Qt Company, похоже, начался синдром Марка Шаттлворта.
Во-первых, NIH-синдром. Во-вторых, закончился. И, да, у Qt Company.
Закончится он, когда они дропнут Qt и перейдут на GTK.)
> Во-первых, NIH-синдром. Во-вторых, закончился.Возвратный NIH-синдром — это как раз и есть болезнь Марка.
Этой QBasic? В линуксе?
Жаль, хорошая и перспективная была вещь. В итоге убита внутренней грызней в Qt. Теперь её выживание зависит от того, сумеют ли её отвязать от Qt.
Проще заново написать, чем такое отвязывать.
Зачем QML-style систему сборки отвязывать от Qt?
А вот от QtScript - да, желательно бы. Возможно, одно из причин смерти - как раз-таки недоQMLность.