Сборка программ, да-да

Внезапно существует документация на всё перечисленное, где всё написано. Конкретно тебя интересуют в первую очередь autotools, как самые распространёные, пусть и самые поганые.

https://www.debian.org/doc/devel-manuals#packaging-tutorial может это оно?

используйте ./configure

Это автотулз. Это устаревшее говно. Сейчас мейнстрим cmake, но он тоже говно. Поэтому шапка проталкивает хипстерский meson и активно переводит на него проекты GTK экосистемы.

Был ещё не менее хипстерский qbs, но его закопали. А он мне больше нравился, чем питонячий meson.

Meson: Gnome, Gtk, Mesa, libinput and etc.

Autotools - это устоявшийся стандарт сборки свободных программ, не слушай этих кукарекающих

https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/auto...

https://www.gnu.org/software/automake/manual/automake.html

https://www.gnu.org/software/make/manual/make.html

systemd ещё.

Autotools Mythbuster расскажет, что autotools, в которые входит automake, autoconf и другое. autogen это скрипт для генерации системы сборки проекта из её исходников. cmake – левая хрень, но тоже система сборки.

1. Можно скачать исходники с сайта программы, внимательно прочитать readme, поставить все нужные dev зависимости пакетным менеджером и тогда уже собирать configure, make, make install или как там. Нерекомендуемый способ, потому что система засоряется неучтенными файлами в обход пакетного менеджера, могут быть конфликты файлов.

2. Можно пересобрать пакет из репозитория дистрибутива. Должен быть подключен source репозиторий. В случае дебиана (убунты) команды такие (на примере vlc):

sudo apt-get install devscripts build-essential dpkg-dev fakeroot patch
sudo apt-get build-dep vlc
apt-get source vlc
cd vlc-3.0.6
debuild -us -uc -b
sudo dpkg -i *.deb

Сборка из исходников засоряет систему множеством зависимостей и dev пакетами. Рекомендуется ставить бинарные пакеты из репозитория или собирать на другой системе (такой же, в виртуалке, например).

Ничем не отличается от сборки программ на виндоус, какие могут быть проблемы? Разве что упаковка пакетов дистроспецифична, но то отдельный разговор.

засоряет

множеством

ну это преувеличение

dev пакетами

не понимаю чем хидеры не угодили, их там на сотню мегабайт. зато потом постоянно ищи в каком пакете хидеры когда надо что-либо внезапно скомпилировать (на этот поиск уходит подозрительно много времени).

sudo dpkg -i *.deb

dpkg не устанавливает зависимости пакета. Надо через apt install ./name.deb

Autotools - это устоявшийся стандарт

Я, конечно, не собираю системные программы, но вот пользовательские регулярно собираю, и там давненько уже не встречал автотулзы, с огромным отрывом лидирует cmake.

на моей домашней локалхостовой гентощке:

# equery depends autoconf | wc -l
246
# equery depends cmake | wc -l
163

Що поделать. Не всех война еще убила. Надеюсь, количество тех, кто пользуется говнотулзами сократится эдак вчетверо.

зачем ты на это надеешься

собирать на другой системе (такой же, в виртуалке, например)

Им дали контейнеры с нулевым оверхедом, нет, будем виртуалки жрать.

Шобы народ собирал софт нормальными системами сборки, такими как Meson+Ninja. Ну, на крайняк Cmake+Ninja.

Во-первых, даже тут видно, что никакой auto уже не стандарт, в лучшем случае первый среди равных. Во-вторых, я же говорил про пользовательский софт — да, всякие баши, coreutils и иже с ними остаются на автотулзах, т.к. им хватает, но вот софт уровнем повыше уже очень редко их использует.

Процесс сборки программы описан в файле README или INSTALL этой программы. Все остальное имеет смысл изучать только в двух случаях:

1) тебе надо передать при ее сборки какие-то особые настройки, про которые в документации не сказано - например, у того же автотулза есть туева хуча стандартных переменных и ключиков, работающих с любой программой. Это особенно полезно знать, если ты мейнтейнер пакетов в дистрибутиве или хочешь им стать (либо ты простой гентушник, пишешь по вечерам ебилды и хочешь, чтобы твои адовые оптимизиации применялись ко всему на свете)

2) ты хочешь запилить систему сборки в своем собственном проекте

Всё очень очень индивидуально, но с софтом идет инструкция по сборке, и как правило эта инструкция меня не подводит

А мне нравится собирать софт автотулзами, зачем ты мне навязываешь свои предпочтения

И не надо их ставить сразу, а то потащит версию (компоненты) из репозитория того, что ты собирал. Все зависимости и так удовлетворены перед сборкой.

apt разве ставит локальные deb'ы?

Вы хотите поговорить об этом? Как давно это началось?

Да! Как-то я поехал на море и взял с собой мануалы по автоконфу и автомейку

лет 10 назад

Все зависимости и так удовлетворены перед сборкой.

Перед сборкой можно удовлетворять только зависимости, необходимые для сборки. Есть же разделение на dev и обычные пакеты.

apt разве ставит локальные deb'ы?

С некоторых пор.

Автотулзы не дружественны к оффтопику (хотя сейчас есть vcpkg, в котором для их поддержки сделано много)

автотулзы вполне себе собирают под оффтопик и для оффтопика, если уметь

В 2019 пора бы уже понимать отличие контейнеров от виртуализации и почему виртуализация предпочтительнее с т.з. секурити.

P.S. а ещё можно знать, что виртуализация приносит не так уж много оверхеда, если использовать light weight VMM типа firecracker.

секурити
сборка

Окей, держите нас в курсе. Несмотря на то, что у виртуалок ещё имеется довольно много применений, где они предпочтительнее, но сборка в изолированном окружении к этому точно не относится.

Ну так накатай ман для новичков.

Решил все таки изучить процессы сборки программ на linux. Но полазив по интернету не обнаружил толкового разъяснения что да как

Действительно, на Linux не принято что-либо собирать самостоятельно — за пользователя это делают специально обученные люди — «мантейнеры» дистрибутива. И сборка более-менее сложной софтины выливается в геморрой построения собственного изолированного окружения под неё со всеми ей необходимыми библиотеками и средствами для сборки. В противном случае получаешь сборную солянку из установленных пакетов и того, чего ты наворотил, не глядя, что куда пишется.

И сборка более-менее сложной софтины выливается в геморрой построения собственного изолированного окружения под неё со всеми ей необходимыми библиотеками и средствами для сборки.

на Linux

Так везде.

В противном случае получаешь сборную солянку из установленных пакетов и того, чего ты наворотил, не глядя, что куда пишется.

Нет. У меня арч, а пакет нужно собирать для Ubuntu 18.04 и 18.10. Докер отлично для этого подходит. Написал несколько скриптов, которые поднимают контейнер, собирают в нём программу и потом пакуют в deb.

Все бы зашибись, но в autotools что бы сделать сборку для ARM мне достаточно указать --host=arm-linux-gnueabi, а в cmake я должен прописать какую то непонятную мне хрень.

+1

Конечно собирают, даже для cl.exe обертки есть

вот-вот, автотулзы рулят )

В 2019 пора бы уже понимать отличие контейнеров от виртуализации и почему виртуализация предпочтительнее с т.з. секурити.

Тут кто-то пакеты с вирусами собирает?

На самом деле, сборка нормального проекта — довольно простое дело.

Читаешь readme и выполняешь, что там написано.

Если в readme ничего про сборку не написано, смотришь, что лежит в корне проекта. Если есть configure, запускаешь его, а затем make. Если configure нет, но есть CMakeLists.txt, значит проект собирается при помощи cmake. Создаешь прямо в проекте директорию build (или любую другую, если build уже занята, название не имеет значения), переходишь в нее, запускаешь «cmake ..» и make.

Если в проекте нет ни configure, ни CMakeLists.txt, но есть autogen.sh, запускаешь его, он сгенерирует configure, дальше по накатанной.

Если в корне просто лежит Makefile, сразу запускай make.

Если ничего из этого нет, то тут уже зависит от проекта, ищи что-нибудь связанное с meson, scons, gyp. И гугли как собирается конкретная система сборки.

Если не хватает какого-то файла (хедера, утилиты или еще чего подобного), ставишь приложение apt-file, один раз запускаешь apt-file update и затем моментально имешь пакет с любым неустановленным файлом при помощи apt-file search uninstalled-header.h

Да, все это относилось к приложениям, написанным на C/C++. Проекты, написанные на других языках, собираются каждый по разному, тут уже нужно смотреть в сторону конкретного языка.

По поводу checkinstall. По умолчанию, если ты делаешь make install, то он все собранные файлы пытается закинуть в /usr/local/{bin, lib, share и т.п.} в лучшем случае и в /usr/{bin, lib, share и т.п.} в худшем случае. При этом эти файлы, естественно, не отслеживаются пакетным менеджером и очень скоро становится непонятно, откуда что взялось и как это все удалить. В теории, если осталась директория с исходниками, то make uninstall должна удалить все, что было установлено make install, но это нужно сохранить ту конкретную директорию с исходниками и надеяться, что автор приложения нигде особо не накосячил.

Правило простое. Если хочется просто посмотреть, что получится при сборке и не устанавливать это в систему на постоянной основе и приложение собирается в один бинарник (без своих расшаренных либ), то просто запускаешь make без install и ковыряешься в собранных файлах. Если все же приложение более сложное, то при запуске configure можешь передать ему в префиксе путь куда устанавливать приложение, напр., ./configure --prefix="/home/vasia/test_prog", после этого make install установит тебе приложение именно в это место. Дальше, переопределив переменные окружения PATH и LD_LIBRARY_PATH можно запустить проект.

Если не хочется возиться или хочется поставить проект в систему надолго, то можно заюзать все же checkinstall. Он создаст что-то вроде виртуальной среды, в ней запустит make install и попытается отследить куда make расположет собранные файлы. И на основе этого сгенерирует уже готовый deb пакет, который ты сможешь легко поставить/удалить при помощи dpkg. Но checkinstall, зачастую, работает довольно косячно. Проще завести где-нибудь в домашней директории директорию opt и просто туда ставить самостоятельно собранные приложения, каждое в отдельную поддиректорию. Так они не будут смешиваться между собой и системными файлами.

Спасибо большое. Довольно доходчиво. По поводу checkinstall запомню, а то я уж подумал что это идеальный вариант установки.

Если в проекте нет ни configure, ни CMakeLists.txt, но есть autogen.sh, запускаешь его, он сгенерирует configure, дальше по накатанной.

Если в проекте нет ни configure, ни CMakeLists.txt, ни autogen.sh, но есть configure.am и Makefile.am, запускаешь:

autoreconf -fiv

Выбросить ninja, ибо помойка. И заменить на samurai.