Чому у makefiles має бути встановлена ​​мета "встановити"?

Походить із світу C та C ++, більшість систем побудови мають installціль, зокрема Makefiles (де, наприклад, рекомендує GNU ) або CMake . Ця мета копіює файли виконання (виконувані файли, бібліотеки, ...) в операційну систему (наприклад, в C:\Program Files\Windows).

Це відчувається по-справжньому хакі, оскільки для мене це не відповідальність системи збирання за встановлення програм (що фактично є обов'язком оператора / менеджера пакетів). Це також означає, що система збирання або сценарій збірки повинні знати організацію встановлених програм, зі змінними середовища, змінними реєстру, символьними посиланнями, дозволами тощо.

У кращому випадку в системах побудови повинна бути releaseціль, яка виводить встановлену програму (наприклад, .debабо .msi), а потім люб'язно попросіть операційну систему встановити цю програму. Це також дозволить користувачу видалити без необхідності введення make uninstall.

Отже, моє запитання: чому система побудови зазвичай рекомендує мати installціль?

Багато сценаріїв створення або Makefiles мають ціль встановлення тому, що вони були створені до існування менеджерів пакетів і тому, що навіть сьогодні багато систем не мають менеджерів пакетів. Крім того, існують системи, де make installнасправді є кращим способом управління пакетами.

makefileМоже не мати installцілей, і що більш важливо, ви можете мати програми , які навіть не мають бути встановленими (наприклад , тому що вони повинні працювати з їх каталогу збірки, або тому , що вони можуть працювати в будь-якому місці встановлено). installМета просто умовність для звичайних makefile-s.

Однак багато програм вимагають запуску зовнішніх ресурсів (наприклад: шрифти, бази даних, файли конфігурації тощо). І їх виконуваний файл часто робить певну гіпотезу щодо цих ресурсів. Наприклад, ваша bashоболонка, як правило, читає якийсь файл ініціалізації з /etc/bash.bashrcтощо. Ці ресурси, як правило, знаходяться у файловій системі (див. Hier (7) для угод про ієрархію файлів), а шлях до файлів за замовчуванням будується у вашому виконуваному файлі.

Спробуйте використовувати рядки (1) для більшості виконуваних файлів вашої системи. Ви дізнаєтеся, які шляхи до файлів відомі йому.

BTW, для багатьох програм GNU autoconfви можете запускати, make install DESTDIR=/tmp/destdir/не використовуючи root. Потім /tmp/destdir/заповнюються файли, які слід згодом упакувати.

FWIW, я схильний вважати, що мою програму bismon (GPLv3 + з ліцензією) (описану в моєму звіті bismon-chariot-doc.pdf ) не можна "встановити"; Я не впевнений, що зможу довести це, і не можу уявити, як я міг зробити цю програму інстальованою.

Є кілька причин, які приходять в голову.

• Багато програмного забезпечення для створення пакетів - наприклад, система збирання Debian та, наприклад, IIRC rpm - вже очікують, що сценарій побудови "встановить" програму в якийсь спеціальний підкаталог. Таким чином, він рухається зворотною сумісністю в обох напрямках.
• Користувач може захотіти встановити програмне забезпечення в локальний простір, наприклад, у $HOMEкаталозі. Не всі менеджери пакунків підтримують це.
• Ще можуть існувати середовища, у яких немає пакетів.

Однією з причин, яка не згадана, є багато випадків, коли ви не використовуєте поточну версію програмного забезпечення або не використовуєте модифіковану версію програмного забезпечення. Спроба створити спеціальний пакет - це не лише більша робота, але це може суперечити поточним створеним та розповсюдженим пакетам. У відкритому коді цього трапляється дуже багато, особливо якщо в нових версіях, які ви використовуєте, внесені порушення змін.

Скажімо, ви використовуєте проект FOO з відкритим кодом, який наразі на версії 2.0.1, а ви використовуєте версію 1.3.0. Ви нічого не хочете використовувати вище, тому що версія 2.0.0 несумісна з тим, що ви зараз робите, але є одне виправлення помилок в 2.0.1, яке вам відчайдушно потрібно. Маючи make installможливість, ви зможете встановити модифіковане програмне забезпечення 1.3.0, не турбуючись про створення пакета та встановлення його у вашій системі.

Дистрибутиви Linux, як правило, відокремлюють підтримку програми від обслуговування пакетів. Система побудови, яка інтегрує генерацію пакунків, змусить утримувачів програм також виконувати обслуговування пакетів.

Зазвичай це погана ідея. У дистрибутивах є багато інфраструктури для перевірки внутрішньої узгодженості, надання бінарних файлів для декількох цільових платформ, невеликих змін для кращої інтеграції з рештою системи та забезпечення постійного досвіду для користувачів, які повідомляють про помилки.

Щоб генерувати пакети безпосередньо із системи складання, вам доведеться або інтегрувати, або обходити всю цю інфраструктуру. Інтеграція цього була б великою працею для сумнівної вигоди, а її обхід дав би гірший досвід користувача.

Це одна з проблем «вершини харчового ланцюга», яка характерна для багатопартійних систем. Якщо у вас є кілька складних систем, потрібно чітко встановити ієрархію, яка система відповідає за координацію всіх інших.

Що стосується управління встановленням програмного забезпечення, цей компонент є менеджером пакунків, і він запустить систему складання пакета, після чого перейдіть до виводу через зручний інтерфейс ("файли в каталозі після кроку інсталяції"), згенеруйте пакет і підготуйтеся його для завантаження у сховище.

Менеджер пакунків стоїть посередині між системою збирання та сховищем тут і знаходиться в найкращому становищі, щоб добре інтегруватися з обома.

Можливо, ви помітили, що існує лише декілька пакетів JavaScript, доступних npmтакож через apt- це, головним чином, тому, що люди JavaScript вирішили, що npmі пов’язане сховище буде вершиною їхнього ланцюга харчування, що зробило його неможливим відправляйте ці пакунки як пакети Debian.

У моїй шапці Debian Developer ввімкнено: якщо ви випускаєте програмне забезпечення з відкритим кодом, залиште упаковку дистриб'юторам. Це економить і вам, і нам багато роботи.

Ну, розробники додатків - це ті, хто знає, куди повинен піти кожен файл. Вони могли залишити це в документації, і вони мають читати це, і створювати сценарій для кожного пакету. Можливо, сервіси пакетів неправильно інтерпретують документацію і доведеться налагоджувати сценарій, поки він не працює. Це неефективно. Краще для розробника програми написати сценарій, щоб правильно встановити написаний ним додаток.

Він може написати скрипт встановлення з довільним іменем або, можливо, зробити його частиною процедури якогось іншого сценарію. Однак, маючи стандартну команду встановлення make install(умова, що передує менеджерам пакетів), робити пакети стає дуже просто. Якщо ви подивитеся на шаблон PKGBUILD для створення пакетів Archlinux , ви можете побачити, що функція, яка насправді пакує, просто виконує a make DESTDIR="$pkgdir/" install. Це, ймовірно, працює для більшості пакетів і, можливо, більше з невеликою модифікацією. Завдяки make(і автоінструментам), які є стандартними, упаковка дійсно, дуже проста.