Russian Qt Forum

Не всё же Igors'у вопросы задавать. Если из темы ничего не выйдет, не беда, форум уточкой поработает.

Итак, сперва контекст. В Qbs у нас есть модули, от них зависит ваша цель сборки (продукт). Модуль может быть чем угодно - языком программирования, фреймворком, библиотекой. Примеры - cpp (https://doc.qt.io/qbs/qml-qbsmodules-cpp.html), Qt.core (https://doc.qt.io/qbs/qml-qbsmodules-qt-core.html). Модули инжектят в продукт разные свойства, например флаги компиляции или библиотеки к которым надо линковаться.

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

Когда в коде пишется Depends { name: "foo" } Qbs сперва ищет "реальный" модуль "foo", если такового нет, то она ищет провайдер foo и пробует создать модуль им, если и такового нет, то используется "fallback" провайдер, который спрашивает у утилиты pkg-config пакет "foo".

У провайдеров можно задавать различные свойства, например чтобы подсказать где искать qmake, надо сделать так:
.
В файловой системе файлы провайдеров лежат примерно так:

Теперь ближе к вопросу.
Я хочу разрешить описывать несколько провайдеров для одного модуля для того чтобы поддерживать разные "источники" - помимо pkgconfig хочу добавить Conan, vcpkg и manual (ручной, где пути к любам надо вбивать ручками) провайдеры. Для этого можно завести новый тип MetaProvider у которого будет (пока) одно свойство - wantedProvider (или список, wantedProviders) - тот провайдер, который мы хотим использовать.
В файловой системе это будет выглядеть теперь так (ну разве что meta-provider.qbs можно звать просто provider.qbs, зачем плодить сущности?):

Аналогично, fallback провайдер выглядит так
Это позволит избежать копи-пасты как в примере выше - pkgconfig может жить только в папочке __fallback потому что единственное его свойство - имя пакета - можно вычислить по дефолту из имени желаемого модуля (спойлер - они совпадают). Ну типа в редких случаях (когда они не совпадают, скажем "zlib" vs "libz") придется описать явно, ну не суть, это делали.

Собственно вопрос в том как синтаксически задавать свойства всего этого зоопарка. Раньше (напомню) мы писали module-providers.<provider-name>.property:value (e.g. module-providers.Qt.qmakeSearchPaths:/opt/bin).
Теперь у нас есть разные уровни провайдеров, есть "главный" и есть "вложенные", "дочерние". Ну, допустим:
Окей, с конкретным модулем разобрались, но ведь неудобно для каждой библиотеки перечислять всё это, нужен "глобальный" синтаксис который ставит значения по умолчанию. Ну допустим:


Опта, коллизия!
Эти две записи имеют синтаксис module-providers.<foo>.<bar>:baz, а значит потенциально влекут кучу проблем (ну например теперь внутренние провайдеры не могут называться как модули)

Собственно, как решить? Проблема тут чисто в именовании, в остальном схема выглядит весьма продуманно.
Например, такое именование (в предыдущей итерации где была другая, но похожая, схема) решает проблему:
Внимательный читатель возмутится - что за пакеты, что за источники? Их больше нет, теперь это MetaProvider и просто Provider. Если мы обобщим схему и вместо "sources" будем использовать "providers" то получается известная субстанция:
Провайдеры? - Провайдеры - Провайдеры! (напевать на мотив developers! developers! developers! (https://www.youtube.com/watch?v=KMU0tzLwhbE))
В общем, я сломал всю голову, никак цветок каменный не выходит. Вроде, схема красивая, но есть нюансы.

Я все-же не понял, а в чем разница между:


и


? Первый - ищет zlib.. ну а второй для чего?

И вообще, непонятны эти нововведения (без 100 грамм ну никак)..

Можешь еще на примерах "реальных" проекта (например в сем же zlib) разобрать на пальцах?

Допустим, у нас проект зависит от нескольких библиотек (zlib, lzma, boost.spirit). И мы хотим использовать Conan при сборке. Тогда мы можем написать

Это слишком многословно и такая гранулярность не нужна (точнее нужна, но в редких кейзах когда 1 модуль ищется через pkgconfig, а второй через Conan, ну потому что аффтары либы не написали .pc файл и pkg-config просто нету). Поэтому хочется уметь задавать значение "глобально", для всех искомых модулей сразу, например, так:

Ну или (тот редкий случай) "по умолчанию" conan но для lzma - pkgconfig:


Хе-хе, мне тоже=) Это далеко не первая версия, возможно третья. Идея в том чтобы позволять выбирать разные "источники" для библиотек. Сейчас поддерживается только один - pkg-config, но его нету на венде, вендузятники страдают.

А почему бы не сократить доступ еще, например так:


т.е. убрать 'wanted' ?

Так, а теперь приведи пример с самой проблемой, я не понял, в чем она?  :)

В чем тут коллизия?


Тут по умолчанию глобально используется pkgconfig и ищет, например, динамик либы по умолчанию. Но мы переопределяем ему св-во static=true, и теперь он ищет только статик либы глобально для всех через pkgconfig.

Но для zlib смысла ставить static нету, т.к. оно итак ищет статику. Мы могли бы для zlib установить:


и тогда бы оно искало только динамические либы... И могли бы опустить вот это:


вообще, т.к. глобально оно и так использует pkgconfig.

Или я не понял?

Например, можем "переиграть" (вот это ниже должно вызывать ошибку):


т.к. тут коллизия, для zlib мы не установили дефолтного провайдера 'conan' и попытались присвоить свойство к еще несуществующему конану.

Вот так бы не было ошибки:


Тут для всех остальных модулей будет юзаться pkgconfig (ищущий что-то с дефолтными настройками, например, динамические либы), а вот для zlib будет использоваться только conan и линковать статикой.

Ну потому что там могут появиться еще проперти. Я уже даже знаю одну - надо ли делать fallback, то есть искать в папке __fallback. Типа MetaProvider (MultiplexProvider, Package, you name it) выглядит так


Вообще, парсер так устроен что он складывает prefix.a.b.c.prop:value в мапу вот так: map["a.b.с"]["prop"] == value. Префикс не может быть пустой, иначе все остальные ключи (вида modules.foo.bar.baz) полетят в эту мапу. Второй ключ (a.b.c) - может быть пустым, то есть "module-providers.wantedProviders" попадёт в map[""]["wantedProviders"]. Prefix сейчас может иметь значения "product", "modules" или "module-providers", соответсвенно оно кладется в 3 разные мапы. Можно добавить новый префикс, если что - см. пример с "packages." выше.


Ну так работать не будет, см выше. Я думал о добавлении сложного синтаксиса типа module-providers.zlib[pkgconfig].static:true, но это надо чтобы парсер QML поддерживал это. Плюс кмк это плохая идея - gyp пошел по этому пути и там было всякое разное разыменование переменных типа <(foo), >(foo), <@(foo), >@(foo) и это имело разное значение. Так себе подход, без пол-литры не запомнишь.

А вот тут будут возмущаться некие немцы. В идеале, wantedProvider превратиться в список wantedProviders и тебе надо будет ставить проперти для нескольких провайдеров сразу. Ну и это надо уже сейчас, например ты можешь захардкодить эти проперти в проекте/продукте сразу:
а выбор провайдера делать с консоли:

Самая засада что сейчас ни у pkgconfig ни у manual провайдеров своих пропертей сейчас нет (пример со static синтетический, скорее всего оно будет не так), но синтаксис придумать надо - они могут внезапно появиться, скажем у Conan.

Ну что пока я придумал (не буду Игорсом который размусолит на неделю, напишу сразу) - не выделять "главный" (мета) провайдер синтаксически и указывать его явно:

Тут есть небольшая неконстистентность - айтем зовется MetaProvider, лежит в папке под именем provider.qbs, а обращение к нему через "main". Хрен запомнишь. Обозвать его Package? Вроде неплохо, запомнить что Package - это мета-информация для выбора провайдеров (и всякая другая) вроде не сложно. Тогда вроде консистентно (ну кроме факта что Package лежит рядом с провайдерами но с этим можно жить, наверное).

А если просто "опускать" main, при этом считаем, что доступ к "корневому" провайдеру тогда будет?


?

Да и wantedProviders слово не нравится. Может заменить на что-то например на factories/sources?

Ну так тут коллизия - это ты как различаешь случаи
module-providers.zlib.wantedProviders:pkgconfig
module-providers.pkgconfig.static:true
а синтаксически оба случая module-providers.a.prop:value. Как понять, а - имелся ввиду модуль а или провайдер а?


Да можно просто providers если не будет коллизий с другими свойствами.

Мне пришла идея в голову, почему это не засунуть в продукт/depends?
Вот так писать неудобно, потому что приходится повторять себя (DRY!)

Поэтому можно сделать, чтобы providers брало значение из аналгичного свойства Продукта, а то - из аналогичного свойтва Проекта

Тогда можно просто писать
"Глобально" устанавливать свойства для определенного модуля, можно так (страшненько, да)

Апну темку :)

Сейчас я пытаюсь решить проблему совместимости со старым кодом.

Как провайдеры работают сейчас - если Qbs не может найти модуль, скажем, Qt.core, она идет и ищет провайдер "Qt.core", если такого нет, то ищет "Qt", который и создает утешные модули. Таким образом, если проект не зависит от Qt.core, то провайдер не вызывается.

Теперь, мы делаем новое свойство qbsModuleProviders: ["Qt", "conan", "pkgconfig"], которое задает порядок, в котором выполняются провайдеры. Сначала работает "Qt", который создает модули для Qt, потом "conan", потом "pkgconfig". Бонусом имеем то, что разные провайдеры могут создавать одноименные модули, но приоритет имеют те, которые раньше в списке - например, если и "conan", и "pkgconfig" предоставляют модуль "zlib", то будет использован от "conan" - очень удобно делать механизм фоллбека между провайдерами.

Также теперь необязательно выполнять провайдеры, когда модуль не найден, можно выполнить весь список ДО поиска модулей - это упростит код в Qbs.
Однако появляется проблема - как быть с дефолтами? Если сделать значение qbsModuleProviders по умолчанию пустым, то сломается автопоиск Qt и pkgconfig. Правда во втором всё равно ничего нет, так что и не проблема=) но вот с Qt это проблема.
Какие варианты есть?
1а. Если qbsModuleProviders пустой, то можно попробовать выполнить ВСЕ провайдеры, которые есть. Это плохо, так как это ужасно медленно (сетап Qt где-то полсекунды, pkg-config 4 секунды чтобы сгенерить все возможные модули, но тут можно оптимизировать).
1б. То же, что 1а, но провайдер говорит, надо ли его звать по дефолту (enabledByDefault: true). Это позволит выключить особо тяжелые провайдеры, но остается проблема - если проект не зависит от Qt, а у Qt провайдера enabledByDefault: true, то юзеру будет непонятно, почему мы пытаемся сетапить Qt
1в. То же, что 1б, но enabledByDefault вычисляется, скажем, по наличию qmake в PATH. Проблему особо не решает, но если проверять, задано ли свойство провайдера qmakeSearchPaths (оно задаётся при запуске qbs setup-qt), то это решит совместимость при использовании Qt-профиля - если юзер явно указал Qt профиль, то наверное он хочет Qt. Но это не решит проблему при автодетекте qmake в PATH - независимо от наличия qmake в PATH мы не знаем заранее, нужна ли юзеру Qt.
2. Ничего не делать и заставить юзера указывать qbsModuleProviders руками в проекте:
Ломается поведение по умолчанию, но можно пока оставить старые реализации провайдеров Qt и pkg-config и при попытке их использовать, выдавать warning - мол, deprecated, задавай qbsModuleProviders явно.
В целом, явное задавание имеет смысл, потому что провайдеры могут создавать не только плюсовые/кутешные модули и, скажем, делать там ["pkgconfig"] по дефолту для Java или там Typescript проекта не имеет смысл.

Какие мысли?