tgoop.com/cpplastic/461
Last Update:
Якийсь дивний прикол, що різноманітні ідеї й раптові висновки зазвичай приходять мені тупо перед сном вже. Востаннє я раптом усвідомив, чому програмісти не переймаються стосовно білд-системи так, як це роблю я. А то парю вам тут щось, а ви дивуєтеся.
Річ у тім, що більшість програмістів… не тямлять в них
По-перше, пересічний програміст не вибирає білд-систему. На роботі таке рішення зазвичай приймає хтось рангом повище: архітектор там якийсь або хоча б техлід. Та і як часто у вас на роботі починаються нові проєкти зазвичай? Ви приходите в компанію, а проєкт там вже триває, ви йдете — а він досі є. Білд-система вже вибрана й працює. Трапляються поодинокі випадки міграцій, як ото в нас була з QMake на CMake, але це рідкість.
Якщо ж ви робите пет-проєкт, то берете те, з чим вже знайомі, тобто те, що було на роботі. Тобто вибір теж відсутній.
По-друге, мало хто з програмістів підтримує або модифікує процес побудови. Докинути в білд пару нових файлів або лібу — це одне, а прям поміняти щось — то зовсім інше. Цим займається переважно якась одна, ну максимум дві людини, які розібралися в цьому трохи краще. Навіть в коментарях у мене писали, що в них так влаштовано все. І, мовляв, «навіть мейкфайли норм, нащо ще щось?» Але той, хто бачив хоч раз білд з десятка-другого не дуже вдало переплетених мейкфайлів, потім пів року чілить на рега́бі з ПТСР.
По-третє, програмісти не паряться щодо фінального постачання. Багато хто чогось переконаний, що зона їхньої відповідальності закінчується в момент, коли коміт запушений. Як результат: від білд-системи треба лише, щоб проєкт запускався з IDE або з термінала. А сучасні IDE й білд-системи цей процес намагаються максимально спростити: вони «за кадром» докидують шмат власного середовища — якісь змінні оточення, якісь теки, де шукати ліби, яких у користувача не буде, тощо. Я протягом років з такою ментальністю у своїх командах доволі багато боровся зі змінним успіхом.
Якщо мова, наприклад, про настільний застосунок, то мій критерій такий: воно має запускатися подвійним клацанням з провідника/файндера. Скільки раз таке було, що з IDE все працює, а просто з теки ні — навіть не полічити вже.
По-четверте, є ціла низка питань, над якими програмісти навіть не замислюються. У тому ж прикладі з настільною програмою до них можна віднести:
• правильна структура тек у складеній програмі. На вінді, наприклад, всі dll-ки мусять лежати поряд з exe-шником, а в macOS-бандлах своя особлива структура, де все по різних теках, і треба правильно прописати rpath, щоб бінарі знали, звідки вантажити бібліотеки. На лінуксі теж своя атмосфера, яка залежить від того, в якому вигляді ви програму розповсюджуєте.
• додавання іконки програми. На вінді треба в ресурси запхати ico, на макосі покласти в бандл icns і прописати в plist, на лінуксі… по-різному. Причому у вас на вхід пачка png-шок різного розміру від дизайнера. Звідки ті ico та icns брати?
• правильне встановлення 3rd-party залежностей. Треба спочатку з'ясувати, а які вони, ті залежності. Без чого програма не працюватиме? Потім динамічні бібліотеки розкласти по своїх місцях, тули по інших; якщо залежите на опенсорс, то треба ліцензії всі у своїй програмі перелічити десь тощо.
• інсталятори… Ви все зібрали, розклали по теках правильно, а тепер треба з цього зібрати дистрибутив. DMG на macOS, якийсь Inno/NSIS/Wix на вінді, DEB, RPM, AppImage і Flatpak на лінуксі.
І врешті треба зробити, щоб усе це відбувалося автоматично. Тобто треба CI. Яке там середовище? Звідки там мають братися всі ті ваші зовнішні залежності, якщо їх бракує? Якщо вони встановлюються звідкись щоразу, то це ж довго, треба кеш або контейнери якісь. А як збирати під різні платформи? Кроскомпіляція чи по серверу на кожну? Чи віртуалки?