Представлен выпуск сборочного инструментария Qbs 1.20. Это седьмой выпуск после ухода компании Qt Company от разработки проекта, подготовленный силами сообщества, заинтересованного в продолжении разработки Qbs. Для сборки Qbs в числе зависимостей требуется Qt, хотя сам Qbs рассчитан на организацию сборки любых проектов. Qbs использует упрощённый вариант языка QML для определения сценариев сборки проекта, что позволяет определять достаточно гибкие правила сборки, в которых могут подключаться внешние модули, использоваться функции на JavaScript и создаваться произвольные правила сборки...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=55965
qml оказался хуже шитоязыка cmake?
qml для разметки гуя же. и в целом он няшный. а cmake тяжело переплюнуть в шитовости
Ну, сам синтаксис (не реализация от Qt) может использоваться где угодно, и быть весьма уместным в разных ипостасях.
В общем-то, везде, где уместен декларативный подход.
Нет, он оказался хуже SQL.
Да, хуже. Ибо qbs не имеет батареек. Вообще в плане батареек лучше всего питон, но для него нормальных батареек для сборки ПО даже проект Meson не написал.
Лучше. Просто лучшее не всегда взлетает.
Идея вообще отличная, а вот реализация...
Правильно, нужно распылять силы сообщества на поддержку устаревшего легаси. Сначала Xorg, потом Devuan, теперь протухший QBS будем накрашивать и одевать в костюмчик, как будто бы он живой.
Уж лучше легаси, чем экспериментальные корпоративные игрушки, на которые у них денег жалко- хотят чтоб бесплатно сделали, вот и нанимают всяких Лёнек, да Дрюшек по объявлению за мелкий прайс.
Да пользуйте свои автотулзы до посинения. Кто ж вам запретит?
ты последний, кого сообщество будет спрашивать, как ему управлять своими силами
А то ты создал что-то новое и офигенно удобное.
А как ты себе представляешь управлять силами сообщества? В приказном порядке что-ли?
> теперь протухший QBS будем накрашивать и одевать в костюмчик, как будто бы он живой.Э... Тролинг?
Лучше QBS еще никто ничего не сделал.
У QBS была одна проблема.
Для того, что бы его собрать - нужен Qt.
А Qt-никам нужна система сборки для сборки самого Qt.
Циклическая зависимость получилась. Ошибка менеджеров на этапе постановки задачи.
> У QBS была одна проблема. Для того, что бы его собрать - нужен Qt.Ещё в Qbs крайне неудобно выполнять свои команды. Надо создать массив на яваскрипте, засунуть в этот массив имя команды и все её аргументы как отдельные элементы массива, и передать массив в специальную функцию. В то время как в Make и CMake можно писать команду и её аргументы в строчку через пробелы, как в шелле.
> Циклическая зависимость
Это как раз не проблема. Для сборки компилятора С тоже нужен компилятор С. Для сборки линкера нужен линкер. Для сборки GNU Make и CMake тоже они сами нужны.
> В то время как в Make и CMake можно писать команду и её аргументы в строчку через пробелы, как в шелле.За это получаешь возможность контроля выполнения задачи.
> Это как раз не проблема. Для сборки компилятора С тоже нужен компилятор С. Для сборки линкера нужен линкер. Для сборки GNU Make и CMake тоже они сами нужны.
Как бы Qt'ники как раз и сказали, что это основная проблема.
C, make и cmake являются самыми распространеными инструментами. Так что требовать их наличие - нормально.
Qt-ники играют вдолгую. Как пример, через пару десятков лет скорее всего C, make и cmake будут. И с очень высокой долей вероятности совместимость особо поломана не будет. А вот бинарник qbs, скорее всего не запустится.
>Обновлён и портирован на C++17 модуль QtScript, который больше не поставляется в Qt 6 и теперь входит в состав Qbs.Т.е., есть надежда, что в последующем они всё, что нужно для Qbs, реализуют у себя и не будут зависеть от Qt.
Более того, был такой план.
такого плана не было, если не считать первоапрельского ишью, в котором еще и на хаскель предлагали переписать.
Что плохого в зависимости от Qt?
Не хуже, чем зависеть от STL.
STL -- это часть стандарта языка С++, а Qt -- непонятное што. Сегодня так, а завтра эдак.
Иди собери 10-летней давности проект, который использует Qt-классы. А с STL нет никаких проблем -- я использую без каких-либо коррекций код, написанный в конце 90-х под C++98. Раз в пару лет пересобираю довольно большой проект и еще ни разу не наткнулся на проблемы именно с STL. А с Qt-классами проблемы возникают с каждой новой версией и всякий раз нужно конкретно разбираться, корректировать код, программную документацию, испытания и прочая волокита.
Что касается gui, то тут просто техническая задница -- проект, изначально написанный с qt3, с грехом пополам удалось отмигрировать на qt4, но на qt5 уже не получилось, поскольку нужно было сохранить функционал и пользовательский интерфейс, включая отзывчивость на консольные события, неизменными. Добиться UI-совместимости не удалось даже в малом. В итоге были вынуждены переписать междумордие на Tcl/Tk.