Russian Qt Forum

Кузулис уже писал на хабре (https://habr.com/ru/post/480132/) про фичи для микроконтроллеров, но вот и официальный анонс вышел (https://www.qt.io/blog/qbs-1.15.0-released).

По ходу это никому не надо :). На опеннете вон, даж заминусовали (лучше там вообще не светиться - обгадят и придется обтекать, а иначе - впитывать).

Ой, на опеннете всегда школота сидела :D

А так, наш форум никому не нужен, а не только Qbs ;) Ты посмотри на остальные темы... Даже про деревянный айтем никто не набрасывает.

А так-то, что ты хотел, после похорон Qbs не мог не случиться отток юзеров, но несмотря на это кто-то используется - периодически возникают вопросы в рассылке, да и баг-репорты заводят регулярно когда что-то ломается.

Я вот на самом деле две недели трахался с msvc и clang-cl чтобы заработал -fsanitize=address и прямо не могу нарадоваться насколько всё просто и красиво получилось. Шутка ли, 200 строк дифф. У меня правда есть чувство что где-то собака порылась, но Qbs и QtCreator с патчем собираются на ура.

Ты, кстати, починил Дискорд?

Не, я потерял ссылку на "канал". Теперь жду когда кто-нибудь добавит упоминание о ней или в документацию или на вики.

есть какая-то утилита для конвертации pro в qbs?

https://wiki.qt.io/Qbs_Quick_Reference/ru русская страница содержит больше инфы, чем английская :)

Вроде нету.

В посте на блоге она есть=)

Ахх, Ёлки, спасибо.

Есть аналог qmake -project:

Сам не пользовался, за работоспособность не отвечаю

Вики я вообще не знаю зачем нужна, она просто скудно дублирует документацию (https://doc.qt.io/qbs/). Все идеи описаны в багтрекере а не в вики, то есть для разработки она тоже не используется. Я бы вообще всю информацию держал в одном месте - в документации. Она хотя бы под тем же версионным контролем, что и код.

Но я тебя вижу в списке участников - тебе надо просто зайти под тем же логином/паролем что ты заходил в первый раз (если ты конечно их знаешь)

работать она работает, но просто собирает все обнаруженные файлы в один qbs верхнего уровня. для простых проектов сойдет, наверное :)

попытался руками написать qbs файлы для https://github.com/kambala-decapitator/qt-test-subprojects, пока застрял на header-only либе. app1 зависит от core и header-only, core зависит от header-only: при сборке получаю
как исправить?

можно вопросы тут задавать или лучше использовать SO/mailing list?

Жаль, могла бы хотя бы по папочкам раскладывать

Проблема в том, что у вас есть два проекта (app1 и core), которые референсят один и тот же проект (header-only). Референсить/включать (по сути, это такой инклюд, только, слава богу, не текстовый, но можно думать о нем и так) один и тот же (под)проект более одного раза нельзя - для подпроекта можно переопределять его дефолтные проперти и если проект подключается с разными пропертями, то неясно, как это обрабатывать (брать первый? второй? брать оба нельзя!)
Обычно делают не так - обычно заводят топлевел-проект, который референсит прямые подпапки и так далее по иерархии папок. А реальные зависимости разгребаются через Depends. В qbs структура Продуктов и (более-менее) Модулей "плоская" - они видны для Depends ото всюду, без привязки к исходной иерархии. Объяснение - вы логически зависите от либы "foo", а не от папки src/libs/foo/ которая может быть где угодно (и да, как следствие, двух либ/приложений с одинаковым именем в проекте быть не может)
То есть, структура папок отдельно, зависимости отдельно (хотя они частично и параллельны).

Просто перенесите
В корневой проект (и создайте его).
Вообще, реальный Project в проекте, как правило, один - на верхнем уровне. Рекурсивные подпапки (ака TEMPLATE+=subdirs в qmake) тоже делаются через Project, но он такой "фейковый" - не содержит ничего, кроме references ниже (https://github.com/ABBAPOH/qbsfish/blob/master/src/src.qbs) (не пугайтесь SubProject (https://doc.qt.io/qbs/qml-qbslanguageitems-subproject.html), в данном случае он полностью эквивалентен references, просто более "декларативно")


В mail листе отвечают достаточно оперативно, насчет SO не знаю. Другое дело что у буржуев щаз праздники и даже коммиты в геррите не ревьювят. Ох уж это время года :)
Задавайте пока тут

большое спасибо, все получилось!

(частично по теме) а как запустить Qt приложение, собранное вне креатора, без модификации rpath? запуск через
не помогает:

Там в какой-то макоси появился DYLD_FRAMEWORK_PATH в дополнение к DYLD_LIBRARY_PATH.
У меня так:
Еще учтите что это может не работать в баш скриптах, безопасности ради эта переменная при каких-то условиях не передается детям. Но из консоли вроде работает.

Еще есть команда qbs run (https://doc.qt.io/qbs/cli-run.html) которая умеет делать это за вас=)


На мне висит тикет (https://bugreports.qt.io/browse/QBS-1204) это документировать, но я ленюсь

DYLD_FRAMEWORK_PATH помог, спасибо. я чисто потестить через терминал :)

с qbs run намного лучше! :)

а как выбрать тип библиотеки-зависимости на лету? хочу, чтоб app1 статически линковалось к core, а app2 — динамически. вот так выдает ошибку:

Javascript
// core.qbs
Product {
  property bool isDynamicLib
  type: isDynamicLib ? "dynamiclibrary" : "staticlibrary"
  name: "core"
  // ...
  Export {
    // ...
    Parameters {
      core.isDynamicLib: true
    }
  }
}
 
// app1.qbs
CppApplication {
  // ...
  Depends { name: "core"; core.isDynamicLib: false }
}

А вот это я вам не подскажу=)

То, как вы делаете, не заведется, параметры в Depends не управляют (как это ни странно) параметрами зависимого продукта/модуля, они нужны, чтобы управлять модулями, от которых сам этот продукт зависит (+1 уровень зависимости). Единственный пример для чего это надо, это чтобы НЕ линковаться к плагинам:

Кажется, это можно сделать через мультиплексинг (https://doc.qt.io/qbs/multiplexing.html), но это тема, в которой я не особо шарю.
Идея в том чтобы собирать проект в два прохода - один раз для "статического" профиля (https://doc.qt.io/qbs/qml-qbslanguageitems-profile.html) и один для "динамического".
Как это сделать и будет ли работать - ума не приложу, никогда не было нужно=)

Ой нет, что-то я тупанул, можно же проще сделать - через два продукта

Update: Хотя я уверен что придется повозиться с макросами экспорта не венде=(

ага, я примерно так и сделал: https://github.com/kambala-decapitator/qt-test-subprojects/commit/3976584e86155fda34dea9ac7f11df1a87f551a1. может, через модуль можно как-то красивее оформить, чтобы получилось примерно как в https://doc.qt.io/qbs/howtos.html#how-do-i-make-my-app-build-against-my-library — Choosing Between Dynamic and Statically-built Qt Projects.

да, макросы надо будет сделать аналогично sharedLib. еще обнаружил, что просто изменение type вместо использования DynamicLibrary/StaticLibrary не упаковывает либы во фреймворки на Макос :)

когда пытался подобное сделать через qmake, получилось как-то слишком громоздко...

P.S. опечатки нашел в доках :)
1. https://doc.qt.io/qbs/qml-qbsconvenienceitems-qtapplication.html — лишняя } в Depends
2. https://doc.qt.io/qbs/overview.html#build-process — скобки перепутаны везде внутри Rule (второй кусок кода)

Я боюсь вендопроблем, ведь макросы экспорта должны быть пустыми в static либе и непустыми в shared. Возможно, единственный способ собирать дважды с разными макросами соответственно. Вендопроблемы=(


Что в Qbs удобно, это всегда можно посмотреть что и как сделано


Спасибо, поправил (https://codereview.qt-project.org/c/qbs/qbs/+/285298)

переделал на StaticLibrary/DynamicLibrary как выше — все-таки правильнее будет.

наткнулся на спорный момент в документации: https://doc.qt.io/qbs/qml-qbslanguageitems-export.html утверждает
то есть при цепочке StaticLibrary -> DynamicLibrary -> App2 хедеры StaticLibrary должны быть видны в App2, т.к. в StaticLibrary прописано
но без добавления идентичного куска в DynamicLibrary получаю ошибку:
или я что-то неверно понял?

Мне кажется, для этого там должно быть


Само по себе оно вроде не экспортирует зависимость от А. Этой строке в документации 6 лет, скоро в школу пойдет, так что оно могло поменяться - ведь если вы зависите от QtCore и QtXml но наружу торчит только QtCore, то нет смысла экспортировать всё подряд.

спасибо. значит, просто документация не обновлена.

нашел трюк получше как в «производном классе» выбирать тип библиотеки: «базовый класс» наследовать не от Product, а от NativeBinary, тогда доступна упаковка в бандл из коробки, а функционал из Library и *Library не особо-то и нужен (install не планирую).

это баг или фича, что список в https://doc.qt.io/qbs/qbsconvenienceitems-qmlmodule.html и https://github.com/qbs/qbs/tree/master/share/qbs/imports/qbs/base отличается? во всяком случае, недокументированный NativeBinary можно спокойно использовать.

Я на всякий спросил в чатике в дискорде на предмет того правда ли это, если нет, исправим.


Что-то баг, что-то фича. Я бы описал недостающее но понятия не имею как использовать NSISSetup, NetModule, NodeJSApplication и некоторые другие.

Часть айтемов (NativeBinary, Library) являются чисто деталями имплементации и не предполагаются для использования напрямую (и потому не документированы). В простых случаях вы используете верхнеуровневые айтемы, в сложных - наследуете Продукт напрямую.
Например, если ваш юз-кейз чуть усложнить - то есть разрешить собирать не только статик/динамик, а статик/динамик/фреймворк, то нативного бинаря уже не достаточно, придется делать MyLibrary (https://github.com/ABBAPOH/qbsfish/blob/master/qbs/imports/MyLibrary.qbs#L10)

Насчет установки - в философии Qbs это считается (но не является) обязательным - запуск (по-хорошему) должен осуществляться только из установочной директории (например, install-root внутри директории сборки - по дефолту оно во время сборки (!) ставит в `pwd`/<config>/install-root/<install prefix>). Это сделано для того, чтобы частично (или полностью) избежать вышеназванных проблем с DYLD_FRAMEWORK_PATH и/или двойным набором переменных в файлах проекта - install dir и destination dir и/или проверками в коде - мы запущены из установочной директории? мы запущены из сборки?. Так как вам и так и так придется (в реальном проекте) это все куда-то ставить, так почему не делать это сразу?=)
В вашем примере если бы либа была установлена и прописан правильно rpath, не пришлось бы указывать путь в DYLD_FRAMEWORK_PATH, только достаточно указать путь к Qt. Впрочем, ставить либы Qt никто не запрещает и сама qbs так делает (https://github.com/qbs/qbs/blob/master/src/shared/bundledqt/bundledqt.qbs)

спасибо, значит, NativeBinary специально недокументирован и лучше его не использовать.

насколько я понимаю, тогда не получится выставить правильные макросы для винды при вашем предложенном подходе заворачивания StaticLibrary в DynamicLibrary, т.к. в этом случае не осуществляется пересборки с новыми флагами. Во всяком случае, я не вижу -DCORE_LIBRARY в логе сборки https://github.com/kambala-decapitator/qt-test-subprojects/commit/547ddf4f67cba5303f91d4ef9480a8761b588140. И остаются подходы через установку type или использование MyLibrary. Или как-то можно «заинлайнить» все нужные свойства внутрь StaticLibrary и DynamicLibrary (чтоб не копипастить), но без наследования от Product? Group позволяет только файлы группировать, больше я возможностей не нашел...

Ваш способ с наследованием от NativeBinary вполне себе ок, это самое простое, что можно сделать.
То, что он "приватный" - ничего страшного, вряд ли он куда-то денется.

Я, кстати, проверил транзитивность зависимостей - пример действительно конфузящий.
1. Если есть цепочка Depends A <- B <- C <- app
2. А экспортирует инклюды, B экспортирует зависимость от А + свои инклюды, С экспортирует зависимость от B + свои инклюды
3. Тогда в app видно инклюды из A

Если убрать экспорт А из B или B из С, тогда инклюды не видно. То есть экспорты, конечно, транзитивны, но не автоматически транзитивны. Пример во вложении.

спасибо большое за помощь! вернул NativeBinary.

документацию надо будет подправить про транзитивность экспортов :)

и пока последний вопрос :) правильно ли делать хедерные либы Product? как здесь https://github.com/kambala-decapitator/qt-test-subprojects/blob/master/header-only/header-only.qbs

Да, я бы делал так же (https://github.com/ABBAPOH/qbs/blob/constexpr/src/shared/gsl/gsl.qbs).
Продукт вообще базовая вещь для всего