Я обожнюю #QML. Все-таки Nokia сильно випередила час із ним.

Ліричний відступ для тих, хто не в темі: QML — це така мова в 💻. Вона декларативна, тобто ви описуєте, що хочете отримати, а не послідовність кроків для досягнення мети. Всі властивості обʼєктів у ній — реактивні, тобто, якщо ви пишете, що height: width / 2, то значення висоти оновлюватиметься щоразу, як оновилася ширина. Ну й на додачу можна писати локальні обробники сигналів на імперативному 💻, якщо треба. І все це швидко працює й рендериться на GPU. Непогано як для технології 2009 року отже.

Люди, правда, зазвичай ототожнюють QML (мову) і Qt Quick (один з UI-них фреймворків від Qt), але мову можна використовувати не тільки для UI.

Отож пишу на QML багацько. Останні пів року чи рік з ґітгабівським копайлотом. Проте для робочих проєктів для замовника копайлот не можна використовувати, бо досі з легальними питаннями не розібралися.

Вирішив спробувати приготувати QML-ний копайлот самостійно. Рецепт такий:
1. Беремо Ollama.
2. Додаємо FIM-модель (Fill-in-the-Middle) для QML, скажімо параметрів на сім-тринадцять мільярдів до смаку.
3. Ставимо у VS Code розширення, яке спілкуватиметься з моделлю.
4. ???????
5. PROFIT! 🥳

Гарні новини: модель існує й навіть офіційна від Qt. Ну, взагалі-то навчити з нуля модель такого розміру — дорого й невигідно, тому насправді це Meta-вська CodeLlama, яку дотренували на якомусь відкритому QML-коді типу офіційних прикладів.

Що взагалі робить будь-яка така модель? Ви закидаєте в неї код (текст), воно його токенізує якось (у кожної моделі власний токенізатор), а потім генерує декілька наступних токенів, які ми перетворюємо назад на текст. Тобто ви пишете import , а воно дає наступний токен чи декілька, які з 99% ймовірністю будуть QtQuick\n.

Але код ми не пишемо як повість на друкарській машинці — ми часто повертаємося кудись в середину, щось додаємо, міняємо, видаляємо тощо. Як же бути?

Якщо ми передаватимемо тільки текст до курсора, щоб модель щось додала від себе, то можемо загубити багато важливого контексту після, й доповнення не буде надто корисним.

Щоб розв'язати цю проблему, всі FIM-моделі дозволяють певного роду розмітку (насправді всі інші LLM також). Наприклад, CodeLlama дозволяє передавати їй текст у таких форматах:

<PRE>Текст до курсора<MID>
<PRE>Текст до курсора<SUF>Текст після курсора<MID>
<SUF>Текст після курсора<PRE>Текст до курсора<MID>

Тут токен <MID> каже моделі, що ось з цього місця — твій вихід, будь ласкава.

Погані новини: для VS Code я знайшов якесь розширення Llama Coder, і воно вже вміє працювати з CodeLlama, а також дозволяє вказувати власну модель. Але виявилося, що промпт воно формує у вигляді <PRE>…<SUF>…<MID>, а ці QML-ні моделі якось так дивно перенавчені, що у відповідь на це видають повну маячню.

Вони прям вимагають, щоб формат був <SUF>…<PRE>…<MID>. Довелося форкати розширення й міняти. По дорозі знайшов і виправив ваду з неправильною вичиткою налаштувань, а також додав кропаль покращень від себе.

Це запрацювало, хоча не сказати, що швидко. Точніше прям неприємно на моєму M1 Max / 64 GB — користуватися неможливо. І це 7 мільярдів параметрів, а не 13! Зате повністю локально, і доповнює вельми адекватно, щоправда форматування пливе.

Дивитимусь далі, що з цим можна ще зробити, щоб було зручно. Ненавиджу довгі мануали — треба, щоб однією кнопкою все встановлювалося ))

Декілька років тому 💻 на своєму 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 кинути не можна — треба натомість створювати патчсет на кьютовий ґерріт.

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

Отже, подивилися ми (переважно не я, а друган) на деякі інші системи складання проєктів. Я вже писав про те, чим Qbs замахав і які маю критерії для вибору. А сьогодні розповім про декілька кандидатів.

Build2 — це щось для відірваних від реалій людей шанувальників усього на 💻 (ця система написана повністю цією мовою). Згадати хоча б той факт, що для build2 нема готових бінарів, а натомість треба їх спершу власноруч зібрати з сирців, причому бажано тим самим компілятором, що й свій проєкт! 🤡 Білд-скрипти їхні — це як шел, помножений на мейкфайли (не зміг вирішити, що гірше, тож узяв обидва). Коротше, мʼяко кажучи, ду-у-уже на любителя, і я точно не серед них. Ще й, здається, якісь ретроградні росіянці пишуть. (Проте якщо чисто за фічами дивитися — то насправді вельми непогано).

Швидесенько глянули на Premake. Він прикольний тим, що там скрипти на 💻, все просто й лаконічно. Я б навіть сказав, що занадто просто. На жаль збирання проєктів на 💻 — це біль. Особливо з #QML. Особливо, коли декілька бінарів. Особливо, якщо це потім треба все скласти в application bundle на macOS. І ще насправді Premake нічого не збирає 😆 Він генерує солюшн під VS або ті ж білд-скрипти для Ninja. Комусь це норм — врешті ninja саме для цього і створили — але мені не норм. Однак з усього сьогоднішнього списку він найприємніший.

Попарилися з Meson, і навіть щось вийшло. Але таке… У них там якась власна декларативна мова трохи дивна, хоча й геть проста. І видається, що не можна писати власні кастомні правила — можна хіба що додати custom_target, в якому викликати щось зовнішнє. А моя задача зробити навпаки! Хочу, щоб не треба було купу додаткових тулів встановлювати, бо це ускладнює CI. Якась базова підтримка Qt там вже є й доволі непогана, але мені цього замало. Якби не це, то можна користуватися — і приємніше за CMake 🤮. Документація теж норм, хоча місцями доволі… необширна. Короч, нам ця система не підійшла кропаль, але якщо у вас чисті плюси або, наприклад, 💻, то спробуйте, бо справляє враження стабільного продукту.

З Bazel (у народі — «Василь») знайомство пройшло найшвидше. Чувак вирішив почитати, як у ньому правильно встановити бажаний стандарт C++ для компіляції, і зʼясував, що… ніяк блять 😂 Принаймні кросплатформно. Тобто рекомендований шлях це зробити — руками прописати світчі для компілятора під кожну систему. Красно дякую! Одразу відчувається рука UX-спеціалістів з ґуґла. Інший дружбан пару місяців тому тестував кодінг-здібності Gemini Pro, попросив того створити проєкт на Bazel і дуже радів, коли ШІ-шка страждала над «цим висером інженерної думки, так само, як [він] колись» (цитата). «Карма в дії», — каже 🙂 Ото, власне, на цьому все й скінчилося з цією системою. Так, там підмножина Python 💻 (Starklark), усілякі фічі круті тощо, але організм відторгає — що поробиш.

Краєм ока глянули ще на метівський Buck2. Там до речі теж Starlark, як і в Bazel. Але воно наче заточене під гігантські монорепи й усе таке, тож не наш випадок.

Вибираємо далі.