LINUX.ORG.RU

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

 ,


0

1

Доброго времени суток господа. Решил все таки изучить процессы сборки программ на linux. Но полазив по интернету не обнаружил толкового разъяснения что да как, как правило все статьи это скопипасченные - «используйте ./configure make make-install(но все же лучше checkinstall)». Хотелось бы поподробнее, а именно запутался на таких моментах как: разница make cmake automake, приставки .ac .am и еще autogen итд. Покидайте пожалуйста ссылок или названия книг где подробно описан этот процесс со всеми тонкостями.

Заранее благодарен.

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

anonymous
()

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

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

ox55ff ★★★★★
()

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

ox55ff ★★★★★
()

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

xaizek ★★★★★
()

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
При необходимости вносятся изменения в исходный код. Здесь уже нормальные локальные deb'ы, ставятся пакетным менеджером, но твоя сборка может быть заменена на версию из репозитория при обновлении.

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

anonymous
()

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

linuxnewbie
()
Ответ на: комментарий от anonymous

засоряет

множеством

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

dev пакетами

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

linuxnewbie
()
Ответ на: комментарий от Harald

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

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

gremlin_the_red ★★★★★
()
Ответ на: комментарий от Harald

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

Unicode4all ★★★★★
()
Ответ на: комментарий от anonymous

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

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

gremlin_the_red ★★★★★
()
Ответ на: комментарий от Harald

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

gremlin_the_red ★★★★★
()

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

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

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

annulen ★★★★★
()

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

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от ox55ff

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

Harald ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

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

ox55ff ★★★★★
()
Ответ на: комментарий от gremlin_the_red

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

annulen ★★★★★
()
Ответ на: комментарий от gremlin_the_red

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

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

trex6 ★★★★★
()
Ответ на: комментарий от trex6

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

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

gremlin_the_red ★★★★★
()
Ответ на: комментарий от gremlin_the_red

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

anonymous
()

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

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

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

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

на Linux

Так везде.

i-rinat ★★★★★
()
Ответ на: комментарий от iZEN

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

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

ox55ff ★★★★★
()
Ответ на: комментарий от Harald

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

splinter ★★★★★
()
Ответ на: комментарий от trex6

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

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

annulen ★★★★★
()

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

Читаешь 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 и просто туда ставить самостоятельно собранные приложения, каждое в отдельную поддиректорию. Так они не будут смешиваться между собой и системными файлами.

anonymous
()
Ответ на: комментарий от anonymous

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

kovalev_94
() автор топика
Ответ на: комментарий от anonymous

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

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

autoreconf -fiv
, он сгенерирует configure, дальше по накатанной.

Deleted
()
Ответ на: комментарий от Unicode4all

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

devl547 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.