Я вже неодноразово згадував, що моя найулюбленіша система збирання проєктів — це #Qbs. Базується цей вибір на двох суперобʼєктивних причинах авжеж: 1) на хибному першому враженні, що за мову там використовують #QML (90% збігається, але насправді це не вона, від чого реально палає нерідко), та 2) на тому, що не можу терпіти #CMake 😁

В кьюбсі в найпростішому вигляді достатньо викликати qbs build або навіть qbs run, й він все сам зробить. Втім інколи треба додати пару якихось ключів в команд-лайн, які я безумовно не памʼятаю. Що в таких випадках люди роблять першочергово? Правильно, пишуть qbs build --help. Але це суперечить концепції(!) головного розробника, тому наразі результат отакий:

ERROR: Invalid use of command 'build': Unknown option '--help'.
Type 'qbs help build' to see how to use this command.

Концептуальність — це завжди офігезно авжеж, але не тоді, коли це щодня наламує мені UX. Так, я не можу спеціально для цієї тулзи тримати в памʼяті, що треба писати qbs help build замість qbs build --help, бо в нормальних прогах це тотожні виклики.

Тож я пішов та зробив свій перший внесок в Qbs аж на пʼять рядків коду, який це виправляє 😂 Довелось заради цього навіть gerrit налаштувати собі з його ґітовими гуками.

Сьогодні вмержив 🥳🍾

До речі буквально на днях колупався знов з #Qbs, бо щось у мене не збиралось. І в якомусь з обговорень на дискорд-сервері побачив у чувака аватарку в кольорах, подібних до українського прапору, але не зовсім правильних.

Виявилось, що це лого програми українського виробництва для роботи з викрійками під назвою Valentina (в мене теж виникають запитання, так). А я як раз шукав щось подібне, бо хочемо пошити коту кофтинку 😼, адже підшерстя в нього нема, й буває трохи прохолодно.

Отож я пішов та зробив merge request з новими іконками. Нафігачив їх в #Figma. На мій погляд вийшло нормас як для недизайнера.

Я й досі використовую #Qbs як білд-систему. Не тому, що він прям суперкрутий, а тому, що #CMake я не можу терпіти ще більше. На додачу ми в пет-проєкті використовуємо #Conan, щоб ставити деякі залежності типу того ж spdlog.

Ізі-пізі все, на маку потестив — працює збс. На вінді друган потестив — теж працює. А на віндовому CI, бляха, ні!

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

conan profile detect

Втім не все так просто. Наш self-hosted ранер для GitHub Actions працює як сервіс від імені NETWORK SERVICES, щоб після ребуту він одразу запускався, а не чекав, доки користувач залогіниться. Тож я не можу просто зайти на віндову тачку та викликати цю команду. Ну ок, додав та прибрав степ, який це один раз робить. З цим порішали.

Та не збирається все одно, собака! І найболячіше те, що з одним і тим самим команд-лайном воно видає різні помилки залежно від того, чи я запускаю це сам руками від свого імені, чи це робить ранер.

Схема така, що за задумом треба використовувати Conan як точку входу, а той своєю чергою вже викликає Qbs. Але мене це дратувало, тож я написав так звану Probe для Qbs, яка перед всіма іншими діями викликає Conan, а вже потім продовжує свою роботу. І навіть тут якась чортівня: результати виклику conan install з однаковими параметрами й всім однаковим під тим самим користувачем(!) відрізняються, коли я запускаю це через Qbs або коли вручну. Тобто у мене вже є щонайменше три різні помилки, і я тупо не бачу жодного звʼязку між ними. Наче сліпий навпомацки, намагаюся щось правити й «дивлюся» на результат.

З самим Conan до речі окрема історія теж. У нього налаштування залежать від платформи. Наприклад, на macOS треба передавати os.version, а на Windows версію не можна вказувати. Тобто воно його не ігнорує, а прям каже: «Ти шо, не передавай мені це!» — і падає з помилкою.

Яке ж лайно! 💩 …в якому мені доведеться порпатися далі.

Добре, попередній допис я ще вчора написав. Але вдень у мене відпустка, тож пофіксив я все вночі 😅

Проблема №1: ручний запуск #Conan відрізнявся від запуску зсередини #Qbs. Для останнього є приблизно такий код:

const p = new Process()
p.start(executable, args)

Тут args — це список рядків. І у мене там були рядки виду '-s:a compiler=msvc', '-s:a compiler.cppstd=20' тощо. Прикол у тому, що, схоже, Qbs їх додатково бере у лапки, і це неправильно парситься саме на деяких компах з віндою 🤯 Пофіксив, замінивши кожен з сеттінгів на ['-s:a', 'compiler=msvc'], а потім зробивши .flat(). Важко сказати, як я до цього прийшов — чисто чуйка.

Проблема №2: ручний запуск qbs build з тими самими параметрами, що на CI, видавав інший результат. Виявилося, що… 🥁 параметри були не тими самими. Я помилився в одному символі, коли вказував архітектуру 🤡, а Qbs нічого проти не має. Хочете x64_86 — легко! Хочете x86_65 — будь ласка! Яке ж дно 🤦🏻‍♂️ Але принаймні на тому самому компі зібралося успішно.

Проблема №3: білд на CI все одно не працював. Тут було вкрай важко збагнути, що не так. Допомогла тільки тулза PsExec від SysInternals, бо на вінді немає простого вбудованого способу запустити щось від імені іншого користувача. Коли вже отримав термінал під NETWORK SERVICES, то виявилося, що… conan.exe просто відсутній 😂 І Qbs на це навіть ексепшн не кинув. Типу: «немає бінаря, що я маю запускати? та й хуй з ним, поїхали далі!»

Як так трапилося? Раніше у мене стояв Conan 1.x, який я встановив через Chocolatey. Ну й, власне, він бінарь кудись до себе кидав у C:\ProgramData\chocolatey\bin\, який є у Path. Але я зробив апгрейд до Conan 2.x (власне, у цьому й полягала задача). І виявляється, що для другої версії Chocolatey просто качає інстолер, котрий раніше не існував, і запускає його. А останній ставиться у C:\Program Files\Conan\conan\ та додає цей шлях в Path тільки для поточного користувача 🤦🏻‍♂️ Короч, додав у системний — і все полетіло.

І шо я думаю… Збирання C++ — це, звісно, доволі важка задача, бо є купа нюансів, є легасі рішення тощо. Але це все не виправдовує погані #тулзи. Чи можна на C++ писати хороший тулінг? Та звісно! Але таке враження, що більшість плюсистів просто не знає, що це таке, бо не має досвіду з іншими адекватнішими мовами з нормальною інфраструктурою. Тобто звикли постійно страждати, і вже важко цього позбутися, чи шо? Нє, ну серйозно…

Попри те, що з модулями в 💻 усе погано, я досі не втрачаю надію почати їх використовувати у своїх проєктах. Вже навіть #Qbs додав підтримку.

Отож того тижня сів знову пробувати. Мої два основних компілятори — це MSVC і Clang.

Щодо першого я ще памʼятаю часи, коли його назва була синонімом нестандартної поведінки. Проте (хто б міг подумати‽) зараз Microsoft нерідко навіть випереджає Clang за впровадженням нових фічей. Тож нині з підтримкою модулів із C++20 там наче нема проблем.

З другим все більш-менш ясно й так. Правда ж? 🤔 Принаймні я так колись думав, доки не усвідомив, що на macOS стандартним є Apple Clang, і це геть не те саме, що LLVM Clang. Наприклад, чинна 16 версія еплівського кланга модулі не підтримує, а LLVM-на підтримувала. Ну й узагалі шістнадцята хтозна-коли вже була в LLVM. Зараз чи то 18, чи 19.

Неофіційно ж змусити еплівський кланг використовувати модулі насправді теж можна додатковими світчами. Але разом з ними вмикаються ще так звані Clang Modules, через що в мене були якісь конфлікти з однією з 3rd-party. Покрутив я ті модулі, покрутив, нічого не вийшло — плюнув поки.

Так ось щодо сторонніх бібліотек… Писати власні модулі — це звісно колись буде круто, але хотілося б, щоб і бібліотеки нарешті почали додавати їхню підтримку.

І знаєте шо? Вони додають! Є прогрес! І навіть існує сайт, який цей прогрес трекає: https://arewemodulesyet.org/

З нього чітко видно, що з 2431 бібліотеки, які вони моніторять, аж 22 (ДВАДЦЯТЬ ДВІ) вже мають підтримку модулів! Ще трошки піднапружитися — і заживемо.

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

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