та суміжні теми. Я вже писав раніше неодноразово про Qbs, Xmake та інші. Також писав, наскільки не люблю CMake 
.Моє особисте емпіричне правило таке: якщо виникає потреба в зневаджувачі для ваших скриптів, які перетворюють код на те, що можна запустити, то щось іде геть не так.
Microsoft колись додала можливість налагоджувати CMake-скрипти прямо у VS, а зараз оце побачив тулзу, яку хтось собі навайбкодив з ImGui — dcmake називається.
І перш ніж вебпрограмісти посміються з бідних нативщиків, я вам «напамʼятаю», що якихось 10–15 років тому можна було деплоїти вебзастосунки перетягуванням файлів з локальної теки на віддалену — іншопланетні технології. А зараз список з тудушками не запустиш без компіляторів, бандлерів, мінімайзерів, тришарового докера й обліковки на Cloudflare
Повернімося до нативних програм. Чого так важко-то?
Насправді головна складність навіть не в тому, щоб компілювати й запускати програму (хоча в C++ навіть це випробування, якщо є зовнішні залежності). Локально-то я її запускаю в себе! А от розповсюджувати — це проблема. У ембедерів, до речі, від цього голова так не болить.
Маємо три основні настільні системи та пару мобільних. (Раніше ще Symbian, Windows Mobile та Maemo були — шкода що померли). Пишете ви програму на комп з використанням «кросплатформного» фреймворка на кшталт Qt. Очікування: сьогодні написав, а завтра всі користуються. Для програм рівня калькулятора десь так і буде, а для чогось серйознішого — без шансів.
У кожної ОС своя атмосфера. На вінді
бінарь і ліби всі в одній теці лежать, іконки *.ico, треба інсталятор, треба якийсь там vcredist_x64.exe, автозапуск через реєстр тощо. На macOS 
інсталяторів найчастіше нема (але інколи є!), зате є особливий архів з прогою; сама прога показується як файл, але насправді це тека зі своєю особливою структурою, яка чітко описана в специфікації, але яку всі порушують, навіть сама Apple — ліби в одній теці, бінарі в іншій, ресурси в третій; іконки *.icns (це шо взагалі‽), автозапуск через сраку; треба обовʼязково підписувати всі бінарі ключем (на вінді взагалі-то теж) тощо. На лінуксі 
взагалі зоопарк технологій: бінарі, які запускаються, та бібліотеки можуть лежати по різних теках прямо в системі, а можуть не лежати; може бути AppImage (zip з прогою), може бути Flatpak (контейнер), може бути абишо, може не бути ліб, іконки хтозна-де, ярлики бозна-як.Звісно, можна це все захардкодити в тулінг. Можна знайти спільний знаменник по фічах, але це завжди дуже вузенька множина. Наприклад, механізми для асоціювання файлів з програмою всюди різні. На деяких ОС є унікальні фічі (як той же QuickLook на macOS). А додати сюди ще iOS та Android (або якусь tvOS), то буде ще більше розбіжностей. Жах.
Можна компонувати все статично, і тоді бандлити значно легше, та я поки щось не бачив хороших UI-фреймворків для цього.
під LGPL, та ще й на C++ — таке собі. Без фреймворків писати — забагато зусиль. Памʼятаю, як ми писали редактор для дизайнерів під macOS та вінду. Довелося використовувати щонайменше 5 різних мов: C++, QML, JavaScript, Qbs (фактично несумісний діалект QML), InnoSetup. І це я не кажу про всілякі мови розмітки чи конфігів.
Отже, воно й не дивно, що для систем побудови програм уже зневаджувачі пишуть. Як і не дивно, що контейнеризовані програми з веб-UI перемогли (чи навіть просто запакований бравзер). Працює тепер, правда, все як лайно: повільно й криво.
А тепер лишилося тільки вайбкодом це обмазати додатково. До речі, звернув увагу, що собі можу з ШІ-шкою навайбкодити якусь тулзу — і мені загалом норм. А ось коли хтось інший вайбкодить, то якось навіть лячно запускати
«Не настільки й сильно воно мені треба» гг. Той же dcmake з початку цього допису навіть не запускав урешті 
