Сформирован (http://blog.qt.io/blog/2018/03/28/qbs-1-11-released/) релиз развиваемого проектом Qt сборочного инструментария Qbs 1.11 (http://qt-project.org/wiki/qbs) (Qt Build Suite), который заменит qmake в Qt 6. В отличие от qmake, Qbs не привязан к Qt и изначально рассчитан на организацию сборки любых проектов. Qbs использует упрощённый вариант языка QML для определения сценариев сборки проекта, что позволяет определять достаточно гибкие правила сборки, в которых могут подключаться внешние модули, использоваться функции на JavaScript и создаваться произвольные правила сборки.
Используемый в Qbs язык сценариев адаптирован для автоматизации генерации и разбора сценариев сборки интегрированными средами разработки. Кроме того, Qbs не генерирует make-файлы, а сам, без посредников, таких как утилита make, контролирует запуск компиляторов и компоновщиков, оптимизируя процесс сборки на основе детального графа всех зависимостей. Наличие изначальных данных о структуре и зависимостях в проекте позволяет эффективно распараллеливать выполнение операций в несколько потоков. Для крупных проектов, состоящих из большого числа файлов и поддиректорий, производительность повторной пересборки с использованием Qbs может опережать make в разы - пересборка выполняется почти мгновенно и не заставляет разработчика тратить время на ожидание.
В новой версии:
- В дополнение к свойствам qbs.targetOS и qbs.toolchain, в которых используются списки, предложены аналогичные скалярные свойства qbs.targetPlatform (http://doc.qt.io/qbs/qml-qbsmodules-qbs.html#targetPlatform-...) и qbs.toolchainType (http://doc.qt.io/qbs/qml-qbsmodules-qbs.html#toolchainType-prop), которые проще использовать для задания целевой платформы из командной строки и в профилях;- В модулях обеспечена возможность определения собственных настроек целевых платформ при помощи нового свойства filesAreTargets для элемента Group;
- В дополнение к TextFile добавлен сервис BinaryFile (http://doc.qt.io/qbs/jsextension-binaryfile.html) для чтения и записи бинарных файлов;
- Добавлено свойство cpp.rpathOrigin (http://doc.qt.io/qbs/qml-qbsmodules-cpp.html#rpathOrigin-prop), через которое можно получить значение @loader_path в Darwin и $ORIGIN в других Unix-подобных платформах;
- Добавлено свойство cpp.driverLinkerFlags, предоставляющее возможность определения флагов, которые будут переданы форнтэнду компилятора только при компоновке.
- В качестве версии языка С++ (cpp.cxxLanguageVersion) теперь можно указывать значение "c++17";- Механизм автоопределения GCC-подобных компиляторов теперь учитывает типовые для MinGW префиксы (т.е. корректно определяет файлы типа i686-w64-mingw32-gcc);
- Для задания имён файлов конфигурации предложен новый ключ "config" и возможность передавать аргументы в форме "ключ:значение". Например для сборки проекта для двух конфигураций debug и release можно запустить "qbs config:debug config:release";
- Функциональность "run", используемая в одноимённой команде, теперь
учитывает необходимые для заданного исполняемого файла библиотеки и добавляет пути к ним в переменные окружения (LD_LIBRARY_PATH в Unix,
DYLD_LIBRARY_PATH/DYLD_FRAMEWORK_PATH в macOS и PATH в Windows).URL: http://blog.qt.io/blog/2018/03/28/qbs-1-11-released/
Новость: https://www.opennet.me/opennews/art.shtml?num=48353
>QML, JavaScriptЭ-х-х-х... Ну и хрен с ними. Может хоть веб-программисты порадуются.
Все лучше, чем в cmake
... и эти еще CMakeShitLists.txt
if() else() endif()
add_executable и add_library вместо просто executable и library
уже на что угодно согласен, только бы не это!и QBS хотя бы декларативный...!
дальше еще сам не смотрел... только что сам внезапно о нем узнал... боюсь сглазить...
Неужели QML еще и case-sensitive?!!!
Боюсь даже выяснять!
может хоть на этот-то раз тулзы для C-подобных языков сделали не любители Паскаля и Бейсика...
> Неужели QML еще и case-sensitive?!!!
> Боюсь даже выяснять!Вы все не поняли - эти все три сообщения написал я (один и тот же Аноним).
Про case-sensitive - это я так выразил свою радость, типа что аж не верится, после мучений с CMake.
Да, слегка противоречиво получилось, но это исключительно от радости (честно), сижу тут изучаю QML...Судя по тому, как на это прореагировали, многие мою радость разделяют. :)))
> может хоть на этот-то раз тулзы для C-подобных языков сделали не любители Паскаля и Бейсика...Поставить Паскаль в один ряд с васиками *рукалицо*
>> может хоть на этот-то раз тулзы для C-подобных языков сделали не любители Паскаля и Бейсика...
> Поставить Паскаль в один ряд с васиками *рукалицо**рукалицо* хотя бы знает, что конъюнкция ("и") и "в один ряд" - это никак не одно и то же
и если Паскаль не в одном ряду с "васиками", то от этого он не становится в один ряд с "С-подобными" - *рукалицо* это тоже знает в отличии от
> *рукалицо* хотя бы знает, что конъюнкция ("и") и "в один ряд" - это никак не одно и то же
> *рукалицо* это тоже знает/,/ в отличи/е/ отНе очень убедительный перевод стрелок *рукалицо*
> Не очень убедительный перевод стрелок *рукалицо*А зачем стараться и убедительно переводить, если сам вброс был неубедительным?
> Неужели QML еще и case-sensitive?!!!Например, если речь об этом, переменные openNet и opennet – совершенно разные, и это здорово
А вот компоненты могут начинаться только с большой буквы, и переменные НЕ могут (логично)
> Неужели QML еще и case-sensitive?!!!
> Боюсь даже выяснять!Вы с винды что ли пришли или чему вы удивляетесь?
>Неужели QML еще и case-sensitive?!!!А лучше как cmake - в одних местах case-sensitive, а в других case-insensitive?
> А лучше как cmake - в одних местах case-sensitive, а в других
> case-insensitive?канешна - чтоб только угробив пол-года, можно было разобраться в чужом "творении".
А то ишь, лезут грязными лапами в наш прекрасный код.
> QBS хотя бы декларативныйА значит ещё более трудный для поддержка. Потому что хз, в каком порядке он там что вызывает.
Внезапно, make декларативный.
Внезапно, не декларативный. Порядком вызова команд можно управлять.
> Внезапно, не декларативный. Порядком вызова команд можно управлять.А можно и не управлять. Это достаточное условие для декларативности.
Просто там управлять порядком вызовов неудобно, а управлять целями - наглядно. И это уже _признак_ декларативности.
Учите матчасть!
И покажите из практически применяемых, а не академических, языков хоть один на 100% декларативный или на 100% императивный или на 100% функциональный или на 100% какой-нибудь там еще.
вы и make не умеете, как я погляжу...
Что не так-то?)
JavaScript на сегодня стал одним из быстрейших интерпретирумых языков
Заметно. Бедные Qt-шники даже компилятор для него запилили.
> Заметно. Бедные Qt-шники даже компилятор для него запилили.В Qt он не очень быстрый в сравнении с браузерами или нодой, но при типовом использовании всё более чем на хорошем уровне
>> Заметно. Бедные Qt-шники даже компилятор для него запилили.
> В Qt он не очень быстрый в сравнении с браузерами или нодой,
> но при типовом использовании всё более чем на хорошем уровнеЧто, электрон таки быстрее? О этот чудный диванный мир...
> Что, электрон таки быстрее? О этот чудный диванный мир...Не нужно путать. В электроне обычный веб, а в QML отрисовка на плюсах и опенгл работает
А браузере отрисовка на JS что ли? Не смешно.
> А браузере отрисовка на JS что ли? Не смешно.Как минимум, все нестандартные компоненты - это JS.
Есть инфа, что Qt использует все тот же V8, например...
Так что ваше "не очень быстрый в сравнении с браузерами или нодой" - бред. Он ровно тот же что в браузерах и этой-вашей-ноде.>> но при типовом использовании всё более чем на хорошем уровне
Вы уж определитесь. Типовое использоваение js - как раз браузеры и нода. А вы утверждаете, что в браузере и ноде быстрее... Несогласованность в ваших высказываниях вижу я.
для qml используется собственный движок v4, сделан для скорости работы с qobject, что бы избегать постоянных преобразований в/из js
> Вы уж определитесь. Типовое использоваение js - как раз браузеры и нодаТиповое использование в Qt. Едрить Вы бестолочь, сударь.
> Qt использует все тот же V8
Когда-то давно так действительно и было, но теперь нет. ES6+, к примеру, там нет.
> Несогласованность в ваших высказываниях вижу я
Знаний силу не мне нужно постичь. Спорить не стоит в пространстве неизвестном.
Не путайте QML и js.
QML это простой и понятный декларативный язык. От js он взял лучшее, а именно JSON структуру. В большинстве случаев его и изучать то не требуется. Для декларирования очень удобен. Зря Qt его как js like рекламируют.
К творениям веб-макак вроде nodejs, да и к типичному js коду, он имеет мало отношения.
Как ты логику без JS собрался с QML работать? Чтобы тут диванные теоретики не описывали, но QML язык разметки, прибитый гвоздями к JS.
> Как ты логику без JS собрался с QML работать? Чтобы тут диванные
> теоретики не описывали, но QML язык разметки, прибитый гвоздями к JS.Так-то да, но обычно он используется на достаточно примитивном уровне и очень хорошо вливается в общую концепцию
Настолько примитивном, что необходимость прибивать его гвоздями вызывает недоумение.
> Настолько примитивном, что необходимость прибивать его гвоздями вызывает недоумение.А как иначе? Что использовать для интерфейсной и лёгкой бизнес логики?
JS - идеальный выбор, как ни крутиНу и всегда остаётся C++ way для отрисовки
> JS - идеальный выбор, как ни крутиНу ведь неправда же. Всегда есть набор ЗА и ПРОТИВ.
И выбрали его не потому, что он идеален, а по вполне себе прагматическим соображениям. Под него есть готовый движок, например.
Его никто выбирал. Его притащили адепты из совсем другой области.
>> Настолько примитивном, что необходимость прибивать его гвоздями вызывает недоумение.
> А как иначе? Что использовать для интерфейсной и лёгкой бизнес логики?
> JS - идеальный выбор, как ни крутиДля начала бы отделить интерфейс от бизнес-логики. Декларативный подход с ошмётками на убогом недоязыке выглядит очень смешно.
> Ну и всегда остаётся C++ way для отрисовки
Не остаётся. Из криокамеры вылезай.
> Декларативный подход с ошмётками на убогом недоязыке выглядит очень смешно.На практике это довольно удобно. Желаю успехов с интерфейсом на C++.
> Не остаётся. Из криокамеры вылезай.
Остаётся. Можно бнальные paintы (не стоит). Или с использованием OpenGL. Виджеты, конечно, нельзя (и слава богам).
Что плохого в ноде-то? Серьезно, относительно недавно использую, классная вещь, быстрее всяких Ruby / PHP. Как глоток свежего воздуха после типизированных компилируемых языков.p.s. QML, конечно, нравится больше, он более структурированный, лаконичный и логичный
Ну вот, ещё один фрейворк с языком сравнивает. Фу таким быть.
> Ну вот, ещё один фрейворк с языком сравнивает. Фу таким быть.Где? JavaScript принципиально разный бывает, поэтому корректно отдельно писать, мол JS в ноде, JS в QML
>JavaScript принципиально разный бываетПосле этой фразы мне стало смешно.
> После этой фразы мне стало смешно.Соболезную. Движков JS много и каждый может работать немного иначе.
Допустим, в QML банально нет ES6+ (на самом деле, и не нужно), нет DOM / window / etc -> процесс написания приложения сильно отличается от аналогичного в вебе.
Это как сравнивать C++99 + Qt и C++11, например. Совершенно разные подходы, совершенно разные функции.
Добавили бы что ли в список продуктов просто "*.o", а то приходится костылить через static library.А еще есть пренепреятнейший баг - в каком бы порядке не шли Depends, порядок линковки будет одним и тем же (по алфавиту они там их сортируют или как - хз). И запросто может получиться что в этом порядке нихрена не слинкуется (а поменять нельзя). Приходится костылить и проблемную либу еще раз в cpp.staticlibraries уже дописывать явно.
> запросто может получиться что в этом порядке нихрена не слинкуетсяЕсли не секрет, что у тебя за линкер? Вроде все уже давно нечувствительны к порядку аргументов. Бывает, разве что, в случае лютого г**нокода слинкованный бинарь не работает, но это надо постараться, чтобы такое получить.
дико извиняюсь, а как у вас получается что от порядка компоновки Depends у вас что-то зависит? такое может быть только если библиотеки между собой имеют неявные зависимости? собирал под gcc проект примерно на 40 библиотек, с корректно проставленными Depends все линковалось в нужном порядке. да и пофиг на сортировку в рамках одной цели если честно.
ну или заводите баг им в трекере)
Qbs - это хтонический кошмар с миграцией конфигов каждую минорную версию.
Никакущая документация, явно виден закос под смартфоно-десктопы, ни для чего другого система сборки не затачивалась, будто других тулчейнов и прочего просто не существует.
> Qbs - это хтонический кошмар с миграцией конфигов каждую минорную версию.
> Никакущая документация, явно виден закос под смартфоно-десктопы, ни для чего другого система
> сборки не затачивалась, будто других тулчейнов и прочего просто не существует.Ничего, говорят в Qt6 оно будет по дефолту. Может тогда хоть их будут бить по рукам за постоянные поломки.
Пока развивается и не дефолт. Использовать нан страх и риск, конечно же. Ждем официальный отказ от qmake и хорошей документации.
Gradle и CMake убьют эту поделку.
CMake уже никого не yбbёт. Его самого скоро Meson закoпает.
> Gradle и CMake убьют эту поделку.Угу. Твой мозг они уже убили.