make install linux что делает

Хочется взять и расстрелять, или ликбез о том, почему не стоит использовать make install

Суть сводится к тому, что эту команду в виде «make install» или «sudo make install» использовать в современных дистрибутивах нельзя.

Но ведь авторы программ в руководствах по установке пишут, что нужно использовать эту команду, возможно, скажете вы. Да, пишут. Но это лишь означает, что они не знают, какой у вас дистрибутив, и дистрибутив ли это вообще, может, вы вступили в секту и обкурилисьчитались LFS и теперь решили под свою хтоническую систему скомпилять их творение. А make install является универсальным, хоть и зачастую неправильным способом это сделать.

Лирическое отступление

Как известно, для нормальной работы большинство софта должно быть не только скомпилировано, но и правильно установлено в системе. Программы ожидают найти нужные им файлы в определённых местах, и места эти в большинстве *nix-систем зашиты в код на этапе компиляции. Помимо этого аспекта основным отличием процесса установки в linux/freebsd/whatever от таковой в Windows и MacOS является то, что программа не просто складывает кучу файлов в отдельную директорию в Program Files или /Applications, а «размазывает» себя по всей файловой системе. Библиотеки идут в lib, исполняемые файлы в bin, конфиги в etc, разного рода данные в var и так далее. Если вам вдруг понадобится её обновить, то всё это надо сначала как-то вычистить, т. к. при использовании новой версии остатки файлов от старой могут привести к совершенно непредсказуемым последствиям, зачастую нехорошим. Вероятность этого события не так велика, но оно вам надо на боевом сервере?

И что с того?

Так вот, если вы делали установку напрямую через make install, то нормально удалить или обновить софтину вы, скорее всего, не сможете. Более того, установка новой версии поверх старой, скорее всего, затрёт ваши изменения в конфигах. make install делает ровно то, что ему сказано — производит установку файлов в нужные места, игнорируя тот факт, что там что-то уже есть. После этого процесса совершенно никакой информации о том, что и куда ставилось, получить в удобоваримом виде невозможно. Иногда, конечно, Makefile поддерживает действие uninstall, но это встречается не так часто, да и не факт, что корректно работает. Помимо этого хранить для деинсталяции распакованное дерево исходников и правил сборки как-то странно.

Как бороться?

Поскольку в дистрибутивах пакеты имеют свойство иногда всё-таки обновляться, для решения этой проблемы придумали такую штуку как пакетный менеджер. При его использовании установка происходит примерно так:

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

Если вы по незнанию/лени скопипастили make install из инструкции, то в системе появляются файлы, о которых пакетный менеджер не знает. Со всеми вытекающими, если вам мало того, что было перечислено ранее.

Что делать?

Так что надо собирать пакет.

У меня нет времени, чтобы ***ться с этим, лучше ещё раз сделаю make install, всё просто и понятно!

Спокойно, спокойно. Он у нас за ноги привязан. Всё не так уж страшно и сложно, как кажется на первый взгляд.

checkinstall

Данная чудесная утилита, будучи запущенной вместо make install задаст несколько вопросов, после чего сама соберёт и установит пакет. Всё, при обновлении никаких проблем с вычисткой старого хлама у вас не будет.

Сборка deb-пакета вручную

После чего получаем в свежесозданной директории весь тот набор файлов. Кстати, мы сейчас находимся в fakeroot-окружении, т. е. можно невозбранно менять владельца и права доступа файлов, но физически в системе владельцем останетесь вы сами. Софт же внутри fakeroot-сессии будет получать изменённую информацию, что позволит упаковать в архив файлы с корректными правами.
Далее создадим в «корне пакета» директорию DEBIAN и сложим в DEBIAN/conffiles список всех файлов, которые должны попасть в /etc:

После чего создаём файл DEBIAN/control следующего содержания:

При необходимости там же можно создать скрипты preinst, postinst, prerm и postrm.

«Правильный» процесс с предварительным созданием пакета исходного кода выходит за рамки данной заметки, а потому описан не будет, но для ваших целей оно обычно и не нужно.

Заключение

Как видите, тут нет абсолютно ничего сложного, но выполнение этих действий избавит вас от огромного числа проблем в будущем.

А авторам статей на хабре просьба: пишите checkinstall вместо make install. Не надо давать вредные советы.

Источник

Configure Make Install

Перед установкой

Сначала Вам скорее всего нужно скачать архив с программой, которую Вы хотите установить.

Например, команда для скачивания python3.7:

Затем распаковать архив

И перейти в только что распакованную директорию

В этой директории скорее всего будет находиться скрипт configure

Configure

Бинари уходят в usr/bin
libraries в usr/lib
Проверяется наличие всего необходимого
Создается файл MakeFile

makefile нужны для того чтобы печатать меньше названий файлов и опций вручную.

С их помощью можно делать build только тех файлов, которые изменились.

Make это инструмент, который вызывает компиллятор. Можно указать тот компиллятор который нужен именно Вам.

С помощью инструкций в makefile можно указать какие именно файлы нужно заново компилировать.

В директории находятся три .cpp файла, два .h файла и три .o файла, оставшиеся от прошлой компиляции.

Все они нужны для проекта и не могут быть объединены в один файл.

Известно, что Example.cpp включает в себя файл Second.h и других зависимостей не имеет.

Мы хотим, чтобы при изменении самого Example.cpp либо его зависимости Second.h начиналась новая компиляция Example.cpp а затем новый Example.o линковался со старыми Second.o и Third.o

Для этого напишем Makefile aomake

Отступы нужно ставить табуляцией

Смотрим на последние две строки:

Выигрыш в этой ситуации заключается в том, что нам не нужно было перекомпилировать Second.cpp и Third.cpp мы просто перелинковали уже существующие Second.o Third.o с новым Example.o

Чтобы запустить этот файл нужно к команде make добавить опцию f и название файла

У файла Second.cpp две зависимости: Second.h и Third.h

У файла Third.cpp только одна зависимость: Third.h

Учтём эти зависимости в нашем aomake

Ещё одной полезной опцией является j

Более подробную информацию по Makefile вы можете найти в статье «makefile tutorial»

Install

Источник

Просто о make

Меня всегда привлекал минимализм. Идея о том, что одна вещь должна выполнять одну функцию, но при этом выполнять ее как можно лучше, вылилась в создание UNIX. И хотя UNIX давно уже нельзя назвать простой системой, да и минимализм в ней узреть не так то просто, ее можно считать наглядным примером количество- качественной трансформации множества простых и понятных вещей в одну весьма непростую и не прозрачную. В своем развитии make прошел примерно такой же путь: простота и ясность, с ростом масштабов, превратилась в жуткого монстра (вспомните свои ощущения, когда впервые открыли мэйкфайл).

Мое упорное игнорирование make в течении долгого времени, было обусловлено удобством используемых IDE, и нежеланием разбираться в этом ‘пережитке прошлого’ (по сути — ленью). Однако, все эти надоедливые кнопочки, менюшки ит.п. атрибуты всевозможных студий, заставили меня искать альтернативу тому методу работы, который я практиковал до сих пор. Нет, я не стал гуру make, но полученных мною знаний вполне достаточно для моих небольших проектов. Данная статья предназначена для тех, кто так же как и я еще совсем недавно, желают вырваться из уютного оконного рабства в аскетичный, но свободный мир шелла.

Make- основные сведения

make — утилита предназначенная для автоматизации преобразования файлов из одной формы в другую. Правила преобразования задаются в скрипте с именем Makefile, который должен находиться в корне рабочей директории проекта. Сам скрипт состоит из набора правил, которые в свою очередь описываются:

1) целями (то, что данное правило делает);
2) реквизитами (то, что необходимо для выполнения правила и получения целей);
3) командами (выполняющими данные преобразования).

В общем виде синтаксис makefile можно представить так:

То есть, правило make это ответы на три вопроса:

Несложно заметить что процессы трансляции и компиляции очень красиво ложатся на эту схему:

Простейший Makefile

Предположим, у нас имеется программа, состоящая всего из одного файла:

Для его компиляции достаточно очень простого мэйкфайла:

Компиляция из множества исходников

Предположим, что у нас имеется программа, состоящая из 2 файлов:
main.c

Makefile, выполняющий компиляцию этой программы может выглядеть так:

Он вполне работоспособен, однако имеет один значительный недостаток: какой — раскроем далее.

Инкрементная компиляция

Представим, что наша программа состоит из десятка- другого исходных файлов. Мы вносим изменения в один из них, и хотим ее пересобрать. Использование подхода описанного в предыдущем примере приведет к тому, что все без исключения исходные файлы будут снова скомпилированы, что негативно скажется на времени перекомпиляции. Решение — разделить компиляцию на два этапа: этап трансляции и этап линковки.

Теперь, после изменения одного из исходных файлов, достаточно произвести его трансляцию и линковку всех объектных файлов. При этом мы пропускаем этап трансляции не затронутых изменениями реквизитов, что сокращает время компиляции в целом. Такой подход называется инкрементной компиляцией. Для ее поддержки make сопоставляет время изменения целей и их реквизитов (используя данные файловой системы), благодаря чему самостоятельно решает какие правила следует выполнить, а какие можно просто проигнорировать:

Попробуйте собрать этот проект. Для его сборки необходимо явно указать цель, т.е. дать команду make hello.
После- измените любой из исходных файлов и соберите его снова. Обратите внимание на то, что во время второй компиляции, транслироваться будет только измененный файл.

После запуска make попытается сразу получить цель hello, но для ее создания необходимы файлы main.o и hello.o, которых пока еще нет. Поэтому выполнение правила будет отложено и make станет искать правила, описывающие получение недостающих реквизитов. Как только все реквизиты будут получены, make вернется к выполнению отложенной цели. Отсюда следует, что make выполняет правила рекурсивно.

Фиктивные цели

На самом деле, в качестве make целей могут выступать не только реальные файлы. Все, кому приходилось собирать программы из исходных кодов должны быть знакомы с двумя стандартными в мире UNIX командами:

Командой make производят компиляцию программы, командой make install — установку. Такой подход весьма удобен, поскольку все необходимое для сборки и развертывания приложения в целевой системе включено в один файл (забудем на время о скрипте configure). Обратите внимание на то, что в первом случае мы не указываем цель, а во втором целью является вовсе не создание файла install, а процесс установки приложения в систему. Проделывать такие фокусы нам позволяют так называемые фиктивные (phony) цели. Вот краткий список стандартных целей:

Теперь мы можем собрать нашу программу, произвести ее инсталлцию/деинсталляцию, а так же очистить рабочий каталог, используя для этого стандартные make цели.

Обратите внимание на то, что в цели all не указаны команды; все что ей нужно — получить реквизит hello. Зная о рекурсивной природе make, не сложно предположить как будет работать этот скрипт. Так же следует обратить особое внимание на то, что если файл hello уже имеется (остался после предыдущей компиляции) и его реквизиты не были изменены, то команда make ничего не станет пересобирать. Это классические грабли make. Так например, изменив заголовочный файл, случайно не включенный в список реквизитов, можно получить долгие часы головной боли. Поэтому, чтобы гарантированно полностью пересобрать проект, нужно предварительно очистить рабочий каталог:

Для выполнения целей install/uninstall вам потребуются использовать sudo.

Переменные

Все те, кто знакомы с правилом DRY (Don’t repeat yourself), наверняка уже заметили неладное, а именно — наш Makefile содержит большое число повторяющихся фрагментов, что может привести к путанице при последующих попытках его расширить или изменить. В императивных языках для этих целей у нас имеются переменные и константы; make тоже располагает подобными средствами. Переменные в make представляют собой именованные строки и определяются очень просто:

Существует негласное правило, согласно которому следует именовать переменные в верхнем регистре, например:

Ниже представлен мэйкфайл, использующий две переменные: TARGET — для определения имени целевой программы и PREFIX — для определения пути установки программы в систему.

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

Автоматические переменные

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

Источник

Заметки Дебианщика

debian, linux, php, mongo, oracle, bash

Чарующая магия configure, make и make install

Это небольшая заметка для начинающих линуксоидов, о том что же означают эти три замечательные команды и для чего одни нужны. Начнём, как говорится, с начала. Большинство программ перед использованием надо скомпилировать, то есть преобразовать из текста понятного человеку в набор единиц и нулей, понятных компьютеру. Процесс условно разделён на три этапа: конфигурирование (configure), сборка (make) и установка (make install). Подробности под катом 🙂

./configure

Выполнить настройку параметров конфигуратора можно при помощи ключей и аргументов этих самых ключей, например:

При помощи ключа —prefix=

Вы можете указать директорию, которая в дальнейшем будет выступать как префикс для вашей программы (то есть корневая директория). Это связанно с тем что в мире Linux и не только, существует специальная Иерархия Файловой Системы (HFS) в соответствии с которой любая программа, чтобы работать без ошибок, должна быть собрана и установлена.

В файловой системе есть три основных префикса, относительно которых большинство программ конфигурируется, а именно:

Если открыть любую из этих директорий, то можно увидеть очень схожую структуру, как минимум там будут папки: bin, etc, include, libs, sbin.

Если запустить ./configure без ключей, то префиксом по умолчанию (директория, в которую будет установлена собираемая программа) будет /usr/local, помните это если не можете запустить свою программу, возможно у Вас не прописан путь в PATH.

Кроме ключа —prefix в конфигураторе, как правило, имеется ещё множество других ключей, посмотреть их все можно если выполнить:

Самая важная и простая команда/программа, выполняет запуск процедуры компиляции приложения из исходного кода. Для своей работы данная программа использует специальные файлы Makefiles, в которых подробно описан процесс сборки приложения со всеми параметрами, которые мы указали конфигуратору. Результатом успешного выполнения команды make будет собранная программа в текущей директории.

make install

Данная команда выполняет непосредственную установку приложения в указанную, на этапе конфигурирования, директорию, после выполнения команды make install вы можете запустить свежеустановленную программу.

Послесловие

Чтобы не писать три команды по очереди можно написать их в одну строку:

./configure && make && make install

На самом деле make install так же может выполнить сборку, потому как задача install зависит от задачи all (то есть непосредственно сборки приложения), это означает что этап make можно пропустить и выполнить всего две команды, если записать их в одну строку получится:

./configure && make install

Удачи Вам! И спасибо за то что дочитали!

2 thoughts on “ Чарующая магия configure, make и make install ”

Всё, что нужно знать про эти три команды, так это то, что это отличный способ запомоить систему.

Спасибо огромное за статью,всё чётко и понятно.

Источник

Make install linux что делает

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

Утилита make

Для чего нужен make

Утилита make считывает из специального файла с именем Makefile или makefile в текущей директории инструкции о том, как (при помощи каких команд) компилировать и собирать программы, а также информацию, из каких файлов состоит программа, которую надо «сделать».

Зависимости. Запись вида

Несмотря на то, что зависимости по внешнему виду похожи на правила, make их различает.

В принципе в данном Makefile не помешали бы и строки

Более длинные правила и зависимости.

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

Аналогично после зависимости на следующих строках можно указать команды, при помощи которых ее надо «делать». Например,

При запуске без параметров make пытается сделать самую первую цель из перечисленных в Makefile. Обычно в качестве первой ставят дополнительную цель » all «, зависящую от всех файлов, которые надо сделать для изготовления программы.

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

Если при компиляции или сборке возникает ошибка, то make прекращает процесс, не выполняя последующие команды.

Если возникает необходимость создать свой Makefile, то лучше всего взять за образец Makefile от какой-нибудь несложной программы.

Конфигурация, компиляция и установка программ из исходных текстов

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

Но, поскольку разные клоны довольно сильно отличаются (особенно BSD-системы от SystemV), то написать код, который компилировался и работал бы без изменений на большом количестве систем, практически невозможно. Причем, чем больше программа, тем эта задача сложнее.

Поэтому перед компиляцией надо сначала произвести настройку.

Первые два способа создают файлы настроек, специфичные для данной ОС (обычно это или include-файлы (.h), или же сразу генерируется нужный Makefile). В третьем случае сразу запускается компиляция с параметрами, специфичными для данной системы.

Непосредственно для инсталляции же практически всегда используется специальная цель » install » в Makefile. Т.е. для того, чтобы после компиляции и сборки установить программу, надо дать команду

Компиляция и установка программы Wget

Набрав теперь » make «, запускаем процесс компиляции и сборки, который занимает некоторое время.

По его окончании можно набрать » make install «. Вот и все!

Компиляция программы NetCat

Первым делом развернем архив:

Из файла README узнаем, что для компиляции надо указать команде make тип ОС. То же увидим, и запустив make без параметров:

Беглый просмотр Makefile показывает, что в нем есть цель под названием » linux «. Итак,

Особенности компиляции программ под X-Window

Imakefile и программа xmkmf

К моменту появления системы X-Window проблема различий при компиляции под разные клоны Unix стала уже широко известна, и был разработан способ, позволяющий унифицированно компилировать ПО для X под разными системами.

Тем не менее, большинство программ под X-Window поставляются именно с Imakefile.

Пример сборки и установки программы под X-Window

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

Сначала развернем дистрибутив:

Запускаем xmkmf и затем make :

Теперь, аналогично обычным программам, делаем » make install «:

Источник