Декілька років тому 💻 на своєму World Summitʼі мала доповідь, в якій чувак натякав, що було б цікаво використовувати цю бібліотеку в програмах іншими мовами.

Зараз Qt можна використовувати з C++ (очевидно), плюс є офіційні привʼязки для Python під назвою PySide. Ще промайнули якісь дивні поробки для інтеграції з 💻. На цьому все. Існує безліч неофіційних, та щось довіри до них нема.

Я вже якось згадував, що #QML як мова для використання фреймворка Qt Quick — це одна з останніх вагомих причин, чого я досі користуюся C++. Просто мені подобається робити UI і подобається, коли врешті він працює достатньо швидко й не вимагає 2 ГБ оперативки, як це нерідко буває з туду-програмами на електроні. Втім C++ у своєму поточному стані дійсно далека від приємної мови, хоча я потроху прямує до неї.

Так-от місяць тому пройшов черговий QtWS, де вони нарешті анонсували так звані Qt Bridges. Поки що жодної конкретики, але за їхніми розповідями це якась достатньо високорівнева апішка для інтеграції QML-ного рушія (і, може, не тільки) в програми іншими мовами. Першими їхніми обранцями стали: 💻, Kotlin 💻 і Java 💻, Python 💻, Rust і Swift 🕊. Я особисто найбільше зацікавлений в останньому, бо під час Advent of Code 2024 мені загалом ця мова сподобалася. З іншого боку дуже хотілося б ще мати змогу писати на QML разом з 🦶. Ну й з Janet 👩‍🦰 ще б теж непогано ))

Найбільше в усьому цьому мене зараз хвилює навіть не технічний бік питання, а легальний. Nokia в свій час перевела Qt з GPL на LGPL, що зіграло на руку популяризації бібліотеки. Але зараз ми бачимо, що Qt Group в пошуках додаткових джерел для заробітку робить навпаки: створює нові модулі, інколи попередньо задепрекейтивши «старі» LGPL-ні, і релізить їх тільки під GPL та комерційною ліцензією. Наприклад, Qt Graphs, Qt HTTP Server, Qt Lottie Animation, Qt Quick 3D тощо.

А як хотілося б мати змогу писати UI на QML, а бізнес-логіку на чомусь компільованому, потім збирати це в один невеличкий бінарь — і щоб це все ще й безплатно! 🤑 Хоча, мабуть, легше вже свій рушій для QML написати натомість.

Я користувався й у деяких проєктах досі користуюся білд-системою #Qbs (неодноразово писав вище). Але як же вона мене замахала! Це просто квінтесенція того, як робити не треба.

Почав користуватися нею через очевидні переваги:
1) декларативна мова, що базується на #QML, з можливостями додавати імперативні вставки на 💻;
2) добре структуровані концепції;
3) швидкий білд без проміжних кроків;
4) не 🤮 CMake 🙂

Реальність трохи більш прозаїчна: мова там не QML, а «діалект QML» — семантика значно відрізняється, бо чинні мейнтейнери на QML ніколи й не писали, лол. Імперативні вставки на JS працюють не так, як очікуєш. Дебажити це неможливо. Нема простих способів робити банальні речі, як-от подивитися команди, які при білді запускаються. Думаєте, достатньо написати -v? А ось хєр! у такому режимі Qbs висирає гігатонну логів, які мають бодай-якийсь сенс виключно для розробників самого кьюбса. (Насправді ж треба писати --command-echo-mode command-line 🤕).

Ну а добре структуровані й логічні концепції… постійно стають на заваді! Наприклад, треба мені було задеплоїти разом зі своєю програмою теку з розширеннями QML з самої 💻. Але кьюбс нічого не знає про теки — він оперує тільки файлами, які він називає артефактами. Артефакти позначаються теґами: один артефакт може мати багато різних теґів, а одному теґу можуть належати різноманітні артефакти. Конкретні теґи опрацьовуються певними правилами. Правила містяться у модулях, на які треба додати залежність. Правило завжди має чіткі вхідні й вихідні артефакти. З усього цього Qbs будує граф правил. Але кьюбс ніколи не робить зайвої роботи — це його фішка. Він будує тільки те, що мусить. І все завжди починається з вашого найголовнішого продукту, який також має теґ.

Тобто білд-система дивиться, і така: «Ага, оцей продукт — це артефакт з теґом application. Звідки його взяти?» — і починає шукати правила, які дають на вихід application. Таким правилом є, наприклад, те, що викликає компонувальник. Воно своєю чергою вимагає на вхід якісь артефакти на кшталт obj, staticlibrary і таке інше. Де взяти їх? Ну, obj можна отримати з cpp. Ви зрозуміли, короч. Хоча це все вельми спрощено.

Прикол у тому, що якщо раптом для побудови фінального продукту кьюбсу не треба зачіпати якісь конкретні теґи, то він і не буде. Я так писав модуль для автоматичного збирання залежностей для моїх QML-файлів, додав його у білд — а воно нічого не робить. І зазвичай геть не очевидно, чого саме.

Інша тема, що всі артефакти — це унікальні сутності, навіть якщо фізично вони вказують на одні й ті ж файли. Так, я раніше написав, ніби це тотожні штуки, але не зовсім. Зібрав я, значить, залежності для QML-файлів — це певні ліби з самого кьюта. Є в мене Foo.qml, якому потрібні qlib1 і qlib2, а є Bar.qml, якому потрібні qlib2 й qlib3 — фізично всі ці ліби лежать у теці з кьютом, але для кожного продукту я створюю «віртуальні» артефакти, щоб все це правильно бачила білд-система. Потім я всі ці залежності хочу встановити в цільову теку програми. А ніііііфііііігаааа! 😡 Qbs такий: «ти встановлюєш qlib2, але там вже лежить інший!» — сґітісаI еґґоґ.

Додати до цього всього ду-у-у-уже специфічний спосіб описувати модулі й правила, причому на ES5, практичну неможливість побачити свій проєкт «очима Qbs», бажано візуально, відсутність просторів імен, що ставить хрест на перевикористанні деяких штук у різних проєктах, тяжку взаємодію з єдиним доступним там менеджером пакетів — Conan (як альтернативу радять pkg-config… у 2k25…), а також майже нульові можливості для зневадження проблемних білд-скриптів — і не лишається майже нічого, за що можна було б зачепитися (окрім того факту, що це досі не CMake 😂).

А, і ще сорци хоч і лежать на ґітгабі — але там чисто дзеркало. PR кинути не можна — треба натомість створювати патчсет на кьютовий ґерріт.

Отже, подивилися ми з друганами на все це вкотре й вирішили, що час щось міняти. Але на що саме? Один з нас розпочав аналіз альтернатив, згодом долучився я, і… здається, нам вдалося знайти непогані варіанти. Днями розповім.