Комментарии 6
я конечно извиняюсь, но...
Компания Qt Company приняла решение прекратить разработку сборочной системы Qbs, использующей упрощённый вариант языка QML для определения сценариев сборки проекта. Ожидалось, что Qbs заменит qmake в Qt 6, но планы изменились, и теперь основные усилия будут направлены на обеспечение поддержки сборочных систем qmake и CMake, с переходом на CMake в качестве основной сборочной системы для Qt в долгосрочной перспективе
новость 2018 года
0
Благодаря декларативному синтаксису, работать с этой системой сборки одно удовольствие, проекты получаются простыми и достигается максимальное переиспользование кода.
Что правда — то правда.
Постоянно в проектах предпочитал и предпочитаю использовать Qbs && QtC. Это гораздо проще и быстрее чем CMake (но это мое ИМХО, а так, конечно, всЁ на любителя).
я конечно извиняюсь, но...
Ну вот, опять… Не надоело еще? Везде где в темах упоминается о Qbs появляются такие личности, которые готовы что-то да вбросить… Прошло уже 2 года, а поток этих «вбросов» всё не уменьшается.
0
Никакая не правда. Там же сплошные if/else и var в примерах. Это императивщина.
0
Там можно и так и так (кому как удобнее).
0
Что-то давно не заходил на Хабр, пропустил комментарий.
Отличие Qbs/Qml от того же CMake в том, что первично — свойство или поток исполнения в файле/файлах. В CMake при рефакторинге постоянно наталкивается на то, что порядок исполнения важен — перенес блок кода выше и уже используешь переменную, которая присваивается ниже. Плюс еще область исполнения в CMake «глобальная» — по факту все дерево файлов превращается в один огромный скрипт.
Свойства этих проблем лишены — Qbs сама разрулит зависимость между ними и вычислит их в нужном порядке, где бы они не были объявлены в файле (ну или ругнётся если зависимость циклическая). Императивность локализована внутри свойств и порядок вычисления не влияет на другие свойства.
Потом, для примеров написать ветку ифоф проще, чем городить, скажем, наследование — никто не мешает объявить базовый модуль, скажем DefaultCppFlags.qbs и сделать пачку наследников, фильтрующих себя в зависимости от платформы/тулчейна — это будет более декларативно (1 файл — одна платформа/тулчейн). К слову, даже убогий qmake так и сделал — каждый mkspec объявляет свойства под одну платформу.
Отличие Qbs/Qml от того же CMake в том, что первично — свойство или поток исполнения в файле/файлах. В CMake при рефакторинге постоянно наталкивается на то, что порядок исполнения важен — перенес блок кода выше и уже используешь переменную, которая присваивается ниже. Плюс еще область исполнения в CMake «глобальная» — по факту все дерево файлов превращается в один огромный скрипт.
Свойства этих проблем лишены — Qbs сама разрулит зависимость между ними и вычислит их в нужном порядке, где бы они не были объявлены в файле (ну или ругнётся если зависимость циклическая). Императивность локализована внутри свойств и порядок вычисления не влияет на другие свойства.
Потом, для примеров написать ветку ифоф проще, чем городить, скажем, наследование — никто не мешает объявить базовый модуль, скажем DefaultCppFlags.qbs и сделать пачку наследников, фильтрующих себя в зависимости от платформы/тулчейна — это будет более декларативно (1 файл — одна платформа/тулчейн). К слову, даже убогий qmake так и сделал — каждый mkspec объявляет свойства под одну платформу.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Qbs: Шаблон настольного приложения