Qbs 1.15.0

[kambala]

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

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

[kambala]

а как выбрать тип библиотеки-зависимости на лету? хочу, чтоб 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 }
}

app1/app1.qbs:1:1 Error while handling product 'app1':
app1/app1.qbs:1:1 Parameter 'core.isDynamicLib' is not declared.
app2/app2.qbs:1:1 Error while handling product 'app2':
app2/app2.qbs:1:1 Parameter 'core.isDynamicLib' is not declared.

[Авварон]

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

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

Код:

Depends { name: "myplugin"; cpp.link: false }

Кажется, это можно сделать через мультиплексинг, но это тема, в которой я не особо шарю.
Идея в том чтобы собирать проект в два прохода - один раз для "статического" профиля и один для "динамического".
Как это сделать и будет ли работать - ума не приложу, никогда не было нужно=)

[Авварон]

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

Код:

StaticLibrary {
    name: "foo-static"
}

DynamicLibrary {
    name: "foo"
    Depends { name: "foo-static"; cpp.linkWholeArchive:true }
}

CppApplication {
    name: "app1"
    Depends { name: "foo-static" }
}

CppApplication {
    name: "app2"
    Depends { name: "foo" }
}

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

[kambala]

ага, я примерно так и сделал: 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 (второй кусок кода)

[Авварон]

ага, я примерно так и сделал: 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.

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

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

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

Код:

 $ cat "/Applications/Qt/Qt Creator.app/Contents/Resources/qbs/share/qbs/imports/qbs/base/NativeBinary.qbs"
...
Product {
...
    property bool isForDarwin: qbs.targetOS.contains("darwin")
    property bool isBundle: isForDarwin && bundle.isBundle
...
    Depends { name: "bundle"; condition: isForDarwin }
...
}

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

Спасибо, поправил

[kambala]

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

наткнулся на спорный момент в документации: https://doc.qt.io/qbs/qml-qbslanguageitems-export.html утверждает

This relationship is transitive, so a product C depending on product B will also get the include paths and preprocessor macros via A's Export item.

то есть при цепочке StaticLibrary -> DynamicLibrary -> App2 хедеры StaticLibrary должны быть видны в App2, т.к. в StaticLibrary прописано

Код:

  Export {
    Depends { name: "cpp" }
    cpp.includePaths: [product.sourceDirectory]
  }

но без добавления идентичного куска в DynamicLibrary получаю ошибку:

Код:

qt-test-subprojects/app2/main.cpp:6:10: fatal error: 'core.h' file not found
#include "core.h"
         ^~~~~~~~
1 error generated.

или я что-то неверно понял?

[Авварон]

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

Код:

Product {
    name: "B"
    Depends { name: "A" }
    Export {
        Depends { name: "A" }
    }
}

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

[kambala]

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

нашел трюк получше как в «производном классе» выбирать тип библиотеки: «базовый класс» наследовать не от 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 можно спокойно использовать.

[Авварон]

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

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

нашел трюк получше как в «производном классе» выбирать тип библиотеки: «базовый класс» наследовать не от 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

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

[kambala]

спасибо, значит, 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 из С, тогда инклюды не видно. То есть экспорты, конечно, транзитивны, но не автоматически транзитивны. Пример во вложении.

[kambala]

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

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

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

[Авварон]

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

Да, я бы делал так же.
Продукт вообще базовая вещь для всего