Здравствуйте.

Вот если я буду собирать проект с нуля, configure ,make, make install.
Я могу быть уверенным, что результат этой сборки будет аналогичен apt-get install, т.е.
все нужные файлы (исполняемые бинари, библиотеки) окажутся в нужных местах? Или он просто
все сложит в папочке, как msbuild на венде в папке bin какой-нибудь?

Ну т.е. можно сказать, configure ,make, make install это аналог build+msi на венде?

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

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте.

S>Вот если я буду собирать проект с нуля, configure ,make, make install.
S>Я могу быть уверенным, что результат этой сборки будет аналогичен apt-get install, т.е.
S>все нужные файлы (исполняемые бинари, библиотеки) окажутся в нужных местах? Или он просто
S>все сложит в папочке, как msbuild на венде в папке bin какой-нибудь?

make install без указания пути под какой ставить — да, будет совпадать.
Но многие варианты позволяют параметр DESTDIR который префиксует все целевые пути.

Ну и не забывай, что после apt-get install в локальной базе пакетов сохранится информация о пакете и всех его файлах, а после make install от autoconf — нет

S>Ну т.е. можно сказать, configure ,make, make install это аналог build+msi на венде?

Msi регистрирует установленное в системной базе?

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте.

S>Вот если я буду собирать проект с нуля, configure ,make, make install.
apt get source забыли там еще патчи будут и версия не последняя

S>Я могу быть уверенным, что результат этой сборки будет аналогичен apt-get install, т.е.
нет. оно даже может не собраться, для начала

S>все нужные файлы (исполняемые бинари, библиотеки) окажутся в нужных местах? Или он просто
S>все сложит в папочке, как msbuild на венде в папке bin какой-нибудь?
после make install оно распихает как задумано

S>Ну т.е. можно сказать, configure ,make, make install это аналог build+msi на венде?
нет
https://www.lrde.epita.fr/~adl/dl/autotools.pdf

Здравствуйте, netch80, Вы писали:

N>make install без указания пути под какой ставить — да, будет совпадать.
N>Но многие варианты позволяют параметр DESTDIR который префиксует все целевые пути.
N>Ну и не забывай, что после apt-get install в локальной базе пакетов сохранится информация о пакете и всех его файлах, а после make install от autoconf — нет

А как удалить потом, вручную?

S>>Ну т.е. можно сказать, configure ,make, make install это аналог build+msi на венде?
N>Msi регистрирует установленное в системной базе?

Вроде да. У него своя база данных или что-то в этом роде. Т.е. помнит что и куда положил.

Здравствуйте, Sharov, Вы писали:

N>>make install без указания пути под какой ставить — да, будет совпадать.
N>>Но многие варианты позволяют параметр DESTDIR который префиксует все целевые пути.
N>>Ну и не забывай, что после apt-get install в локальной базе пакетов сохранится информация о пакете и всех его файлах, а после make install от autoconf — нет
S>А как удалить потом, вручную?

Да. Но вместо make install можно использовать checkinstall — тогда все будет +- прилично.

Здравствуйте, Sharov, Вы писали:

S>Вот если я буду собирать проект с нуля, configure ,make, make install.
S>Я могу быть уверенным, что результат этой сборки будет аналогичен apt-get install, т.е.
S>все нужные файлы (исполняемые бинари, библиотеки) окажутся в нужных местах? Или он просто
S>все сложит в папочке, как msbuild на венде в папке bin какой-нибудь?

Ты можешь быть уверен, что он не будет аналогичен apt-get install. Он раскидает всё в системе в хаотичном порядке. Скорей всего в /usr/local, но не факт. Смотря что взбрело в голову писателю этих скриптов.

Те, кто пакетируют софт, тратят нетривиальный объём времени, чтобы файлы появились там, где положено в этом дистрибутиве.

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

S>Ну т.е. можно сказать, configure ,make, make install это аналог build+msi на венде?

Не знаю, что такое build+msi, тут ничего не могу сказать. В целом не рекомендую на установленной системе делать make install. Я либо собираю пакет с помощью make, потом разбираюсь, какие бинарники куда он положил (обычно в пределах папки с проектом, в какой-нибудь ./build кладёт) и копирую всё сам куда считаю нужным. Либо в виртуалке или контейнере долго и мучительно разбираться, писать свои скрипты, и в итоге собрать dpkg/rpm пакет, который уже и установить на хостовой системе, и в котором всё будет лежать на тех местах, которые ты считаешь правильным. Но это долгий путь, я уже давно это не делал, я бы сказал, что сегодня разобраться со всем этим — пару недель надо потратить.

Здравствуйте, Sharov, Вы писали:

N>>make install без указания пути под какой ставить — да, будет совпадать.
N>>Но многие варианты позволяют параметр DESTDIR который префиксует все целевые пути.
N>>Ну и не забывай, что после apt-get install в локальной базе пакетов сохранится информация о пакете и всех его файлах, а после make install от autoconf — нет

S>А как удалить потом, вручную?

Да.
Потому сейчас вне пакетных средств стараются сконфигурить с самого начала по варианту
./configure PREFIX=/opt/zuka/buka
и чтобы файлы там лежали.

Но в основных дистрибутивах есть средства типа checkinstall (для Debian) которые позволяют из запуска под собой make install собрать сразу пакет. Он будет конечно не совсем полноценным (не будут, например, зачистные скрипты), но все файлы, которые были поставлены в FS — будут зарегистрированы..

S>>>Ну т.е. можно сказать, configure ,make, make install это аналог build+msi на венде?
N>>Msi регистрирует установленное в системной базе?

S>Вроде да. У него своя база данных или что-то в этом роде. Т.е. помнит что и куда положил.

Тогда с добавкой checkinstall будет ближе к аналогу.

Здравствуйте, vsb, Вы писали:

vsb>Ты можешь быть уверен, что он не будет аналогичен apt-get install. Он раскидает всё в системе в хаотичном порядке. Скорей всего в /usr/local, но не факт.

Обычно configure --help описывает, куда можно ставиться какими компонентами вплоть до тонкой регулировки типа конфиги в /etc/buka, бинарники в /usr/bin, библиотеки в /usr/lib/zuka/buka...

vsb>Те, кто пакетируют софт, тратят нетривиальный объём времени, чтобы файлы появились там, где положено в этом дистрибутиве.

Изменить пути как раз обычно тривиальщина. Нетривиально — многие другие аспекты, типа, как организовать линковку именно в нужном стиле.