> Расскажите как модулями управляли, систему сборки использовали, или руками в консоль вводили команды?Раньше GNOME собирался через jhbuild, сейчас не знаю. Это была гномовская управляшка модулями, которая собирала разные куски GNOME. Каждый модуль мог при этом иметь свою систему сборки. jhbuild как раз и выправлял множественные зависимости. У нее там были свои метапакеты/метамодули, не помню.
Суть в том, что в Linux для нативной линоковки вам нужны заголовки на С, а в случае с С++ могут потребовать еще и биндинги к С ради переносимости библиотеки, потому что С++ некроссплатформенный язык со всеми вытекающими последствиями. Часть модулей связывается друг с другом через dbus.
GNOME как проект следил за всеми своими зависимостями, чтобы не возникало проблем вроде тех, которые я писал выше, когда 2 модуля зависят от разных версий третьего модуля. GNOME это делает, потому что это они авторы своих же модулей.
В Go ситуация иная. Там речь не про модули, заголовки и линковку. Там именно что всё сваливается в общий бинарь, код соединяется статически со всеми. И вот вопрос to vendor or not to vendor. Ты либо сам решаешь проблемы совместимости в других проектах, от которых ты зависишь, форкнув их, потому что оно попадёт к тебе в общий бинарь, либо надеешься на апстрим, авось и ходишь к попам на воскресную молитву.
Гошники просто кидают сорцы в Git. Из-за отсутствия возможности динамической линковки им незачем заниматься бинарной сборкой модулей, не за чем поддерживать совместимость самих с собой. Учитывая что большая часть разработчиков на Go не имеет даже такой концепции, как "релиз модуля" и распространяют свой код через систему контроля версий в публичном интерене, иногда без тегов и как попало, то те кто занимается сборкой и доставкой Go в дистрибутивах вынуждены городить инфраструктуру релиза своими средствами.
Почитайте https://docs.fedoraproject.org/en-US/packaging-guidelines/Go.../
Для сборки программы на Go меинтейнеры должны:
1. Отключить при сборке загрузку сорцов с гитхабов и гитлабов авторов-игогошников, потому что им веры нет
2. Опакетить сорцы каждого модуля приложения, сделав релиз за этих бомжей
3. Самостоятельно решить проблему зависимостей зависимостей внутри сборочной системы Go силами дистрибутива с использованием RPM
4. Самостоятельно сопровождать форки кодовой базы и перепакечивать и обновлять
Весь этот язык придумал Google для запуска многопоточных клиент-серверных приложений в форме монолитных блобов внутри Kubernetes. Причем он специально сделан процедурным языком с АЛГОЛ-образным синтаксисом, чтобы людям было привычно и не нужно было использовать erlang. Go - это замена erlang в его нише, ни больше, ни меньше. И вся его простая экосистема создана для этой задачи быть запущенным в контейнере под управлением кубика.
