І на мою думку побудова складних 💻-програм — чудовий контрольний тест. Дивіться самі:
- Qt базується на 💻, а всі знають, що у нас в C++ компілювати складні проєкти зазвичай доволі важко;
- при цьому більшість Qt-програм — кросплатформні (принаймні ті, що пишу я);
- але також Qt — це надбудова над C++, бо там є низка тулів для генерації коду: MOC, RCC тощо — без яких усе це не працюватиме;
- якщо використовувати QML, а я завжди використовую, то ще додається ціла низка тулів, щоб генерувати правильні QML-модулі;
- безплатна версія Qt розповсюджується під LGPL, а значить найпростіший спосіб пакувати програми — через динамічне компонування. А це значить, що треба правильно розкласти побудовані бібліотеки по теках;
- та й загалом структура готової програми на трьох головних десктопних системах відрізняється: на 🪟 ліби лежать під екзешніком, на 🍏 використовуються бандли, на 🐧 просто хаос (tar.gz, AppImage, Flatpak, ну ви знаєте).
Хтось каже мені: нащо ті системи взагалі потрібні — достатньо одного
Makefile. Ну, якщо вам достатньо, то можу лише позаздрити. У переважній більшості моїх проєктів усе трохи складніше:1. Підтримка macOS + Windows + Linux з коробки, а точніше різних компіляторів на цих системах (я не хочу памʼятати й вручну встановлювати параметри під кожний з них).
2. Я люблю пробувати «свіженьке», тому білд-система має підтримувати фічі нових стандартів C++, зокрема модулі, які вийшли ще в C++20.
3. Принаймні базова підтримка Qt: система мусить розуміти структуру цього фреймворку, а також вміти викликати всі ті додаткові тули типу meta-object compiler.
4. Бажано, щоб про QML система також знала.
5. А якщо ні, то свої власні «правила» писати має бути дуже легко! Якщо я хочу запакувати графічні асети в ресурси автоматично або обробити їх перед цим якоюсь тулзою, то не хотілося б витрачати на це тиждень.
6. Я не хочу писати «зовнішні» скрипти для цього, бо це додаткова залежність для хостової системи. Мова системи складання має задовольняти всі базові потреби типу читання/записування файлів, як бінарних, так і текстових, парсинг, виклик зовнішніх утиліт тощо.
7. До речі щодо залежностей: треба якусь зручну роботу з 3rd-parties. Тобто підтримка пекедж-менеджерів на кшталт Conan або vcpkg, або хоча б можливість стягувати щось з інтернетів (без написання власних скриптів знов-таки).
8. Пакування готової програми у звичний для системи формат: інстолери для вінди, DMG на macOS, будь-що на лінукс (там люди все одно звикли страждати). До речі, у сучасності це все треба ще й правильно підписати якимись там сертифікатами. Хто це має робити? Система побудови звісно!
9. Є штуки як той же CMake, які самі нічого не роблять, а тільки генерують інструкції для інших систем штибу make або ninja. Юніксолюби посперечаються, але на мій погляд це дурня якась! Система має білдити все сама, бо я не хочу зайвих залежностей.
10. А взагалі не тільки білдити, а ще й запускати. Мені у 2k25 ліньки шукати в теці build потрібний мені бінарь. Хочу, щоб можна було написати
mega run, якщо уявна система називається mega.11. Я пишу у VS Code, а деякі мої колеги в якихось IDE, тому непогано б мати інтеграції чи принаймні здатність генерувати
compile_commands.json. 12. З роками я дійшов до плюс-мінус узагальненої структури всіх своїх проєктів. Це дуже допомагає бутстрапити нові швидко. Було б круто мати механізм перевикористання хоча б кастомних правил між цими проєктами.
13. Ну й найголовніше: побудова всього проєкту має виконуватися викликом однієї команди! Включно з отриманням усіх залежностей, а ліпше ще й зі встановленням всіх необхідних тулсетів. Не важливо, чи це CI, чи компʼютер розробника, чи ще щось — одна команда на все!
Хіба я забагато прошу?
Не складно зауважити, що багато з цих вимог покриваються сучасними інструментами в інших мовах. Але в мене C++, а це одразу головняк ×10.
Спойлер: ми не знайшли систему, яка б задовольняла всім вимогам. Але деякі виділяються на тлі решти. Досі граємося з ними. Шкода, що часу небагато.