Comments 17
"Извините, но в 2025 году" что мешает использовать базы данных для подобных задач? Почему информацию о системе и подсистемах на складывать в базу данных, а не проверять 100500 раз на каждый чих?
Хороший вопрос, думаю так просто исторически сложилось. Складывание в базу данных тоже имеет свои проблемы, но то, как autotools работает сейчас это топорно, медленно и неудобно.
Актуализация данных в БД будет заведомо более хрупкой, нежели фактическая проверка. Можно сделать это в виде кэша с ограниченным временем жизни, но это не отменяет необходимости параллельного запуска, даже если такой запуск будет реже.
С другой стороны, параллелизм создаёт массу новых проблем: недопустимо, если последовательное и параллельное выполнение теста будет давать разные результаты. Если это оставить на откуп разработчика, то этим никто не станет заниматься, всё будет по принципу "и так сойдёт", иногда вызывая дополнительные неясные ошибки при сборке.
Значит, чтобы это работало хорошо, необходимо централизованно писать наборы стандартных тестов различных библиотек и подсистем так, чтобы они были заведомо независимы и потокобезопасны, и спускать эти готовые тесты пользователям в неизменном виде, а нестандартные пусть выполняются последовательно. Такие тесты желательно писать самим разработчикам библиотек/приложений, с которыми производится взаимодействие, т.е. необходимо в репозитории иметь какой-то набор пакетов с такими тестами, которые будут мейнтейниться разработчиками.
Решение интересное, но чертовски сложное в организации социально.
pkg-config?
Да уж. Как же это медленно и хрупко. Сборка C/C++ библиотек и зависимостей это всегда лотерея - никогда не знаешь, что сломается на этот раз. Я пользуюсь Conan, и он, помимо решения проблем, создает новые.
Кажется, в 25 году пора просто вырезать это все и переходить на что нибудь более вменяемое. Думаю, что на древние юниксы можно уже и забить.
./configure был нужен, когда UNIX существовал в 100500-х вариантах, и задача была собрать данный пакет на данной системе хоть как-то, приспособившись к особенностям системы.
Сейчас система примерно одна, и задача заключается скорее не в том, чтобы приспособиться к ее особенностям, а в том, чтобы получить на разных инсталляциях системы более-менее одинаковый результат, понятным человеку образом затребовав недостающие ресурсы для её достижения.
Это совсем не то, чем занимается /configure.
P.S. Кстати, есть еще такая полезная штука, как pkg-config...
"Извините, но в 2025 году" можно уже не запускать конфиг перед каждой компиляцией...
Или нельзя? (в вашем случае)
Скажем, если собирать образ образ какой-нибудь ОС/контейнера/сдк с зависимостями, для каждого пакета будет дергается довольно медленный configure. В итоге 50+ процентов времени сборки потратится на то, чтобы гонять одинаковые тесты в один потом для каждого пакета.
можно пакеты по зависимостям одного уровня собирать параллельно, конечно это не поможет там где можно:
просто уменьшил количество ненужных проверок
в общем как всегда, все, к сожалению, сводится к тому что все надо просто переписать...
Но, как известно (хотя мало кто об этом помнит), софт придумали именно для того чтобы его можно было просто переписать!
Что только люди не делают, лишь бы не пользоваться cmake в 21 веке
Если бы проблема была только в конфигурации сборки. Большую часть времени занимает сама компиляция, особенно если надо раскрыть все макросы.
Вот вам парочку советов из Gentoo сообщества:
1) создаем виртуальный диск в оперативной памяти tmpfs и компилим на нём.
2) ccache для кеширования сборки
3) distcc для распределённой компиляции
1) создаем виртуальный диск в оперативной памяти tmpfs и компилим на нём.
Много чего компилировал и компилирую, в т.ч. и в генте, но не помню случая, чтобы когда-то компиляция рогом упиралась бы в диск. Ну, конечно, замена хдд на ссд даст наверное 5-10% выигрыша по времени, но не более того (компиляция во все 32 потока на ryzen'е). Потому мне всегда странны рассказы о том, что "заменил диск -- стало в 2 раза быстрее компилироваться". Это наверное не про c/c++ типичные софты, как в линуксах.
причем здесь жесткий диск. вы не внимательно читаете.
не диск поменять, а создать раздел диска в оперативной памяти. скорость работы с файлами в оперативной памяти больше чем на физическом диске.
Если замена хдд, который давал условно 100иопсов и 100 мегабайт в секунду на ссд, где тыщи иопсов и гигабайт в секунду даёт выигрыш хорошо если в 10%, то дальнейнее ускорение рамдиском, где иопсы и бендвиз ограничены скоростью чтения и копирования у процессора, вряд ли магически ускорит хотя бы в 2 раза что-то. C рамдисками я тоже экспериментировал, и ускорение там относительно ssd получалось для компиляции ещё меньше, чем от hdd->ssd.
Мой посыл был о том, что в задачи типичного компилирования c/c++ диск -- самое последнее место, в которое машина упрётся по ограничению скорости компиляции.
Параллельный ./configure