Рекомендуемый FHS-совместимый рабочий процесс тестирования / установки приложений под Linux?

Question

Я нахожусь в процессе перехода на Linux для разработки и озадачен тем, как обеспечить хорошую совместимость с FHS в моих программах.

Например, под Windows я знаю, что всеРесурсы (растровые изображения, аудиоданные и т. д.), в которых может нуждаться моя программа, можно найти по относительным путям из исполняемого файла, поэтому то же самое, если я запускаю программу из своего каталога разработки или из установки (в разделе «Program Files»).например, программа сможет найти все свои файлы.

Теперь под Linux я вижу, что обычно исполняемый файл находится в / usr / local / bin, а его ресурсы - в / usr / local /доля.(И правда в том, что я даже не уверен в этом)

По соображениям удобства (например, для контроля версий) я бы хотел, чтобы все файлы, относящиеся к проекту, имели одинаковый путь, скажем,например, project / src для источника и project / data для файлов ресурсов.

Существует ли какой-либо стандартный или рекомендуемый способ, позволяющий мне просто перестроить двоичный файл для тестирования и использовать файлы в каталоге project / data,и, в то же время, будучи в состоянии найти файлы, когда они находятся в / usr / local / share?

Я подумал, например, установить символическую ссылку в / usr / local / share, указывающую на мой каталог ресурсов, а затем просто жестко закодироватьэтот путь внутри моей программы, но я чувствую, что он довольно хакерский и не очень переносимый.

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

Может кто-нибудь сказать мне или указать мне, где он рассказывает, как эта проблема обычно решается?

Спасибо!

Answer 1

По соображениям удобства (например, для управления версиями) я хотел бы, чтобы все файлы, относящиеся к проекту, имели одинаковый путь, например, например, project / src для источника и project / data для ресурсафайлы.

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

Я вижу, что обычно исполняемый файл находится в / usr / local / bin, а его ресурсы - в / usr / local / share.(И правда в том, что я даже не уверен в этом)

Стандартный префикс - /usr./usr/local для «локальных установок», как повторяет спецификация FHS.

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

Определенно.Запустите ./configure --datadir=$PWD/share, например, это способ указать вашу сборку на файлы данных из дерева исходных текстов (заменить на правильный путь) и использовать что-то вроде -DDATADIR="'${datadir}'" в AM_CFLAGS, чтобы сделать значение известным (предположительно C) -коду,(Все это при условии, что вы используете autoconf / automake. Аналогичные параметры могут быть доступны в других системах сборки.)

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

Answer 2

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

Например, файл конфигурации для полностью развернутого приложения с именем myappможет находиться в /etc/myapp/settings.conf, а часть может выглядеть следующим образом:

...
confdir=/etc/myapp/
bindir=/usr/bin/
datadir=/usr/share/myapp/
docdir=/usr/share/doc/myapp/
...

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

Я считаю, что вы можете разумно предположить в своем коде, что местоположение файла конфигурации фиксировано в /etc/myapp - или в любом другом месте, указанном во время компиляции.Затем вы предоставляете параметр командной строки, позволяющий переопределить это местоположение:

myapp --configfile=/opt/myapp/etc/settings.conf ...

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

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

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

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

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

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

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

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

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

РЕДАКТИРОВАТЬ:

Этот метод не предписанлюбой формальный стандарт, о котором я знаю, но он является распространенным решением в мире Unix.Большинство основных демонов (например, BIND, sendmail, postfix, INN, Apache) будут искать файл конфигурации в определенном месте, но позволят вам переопределить это местоположение и - через файл - любой другой путь.

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

Answer 3

Вы можете просто проверить несколько мест. Например, сначала проверьте, есть ли у вас каталог data в каталоге, из которого вы в данный момент запускаете программу. Если так, просто продолжайте и используйте это. Если нет, попробуйте /usr/local/share/yourproject/data и т. Д.

Для разработки / тестирования вы можете использовать каталог data в папке вашего проекта, а для развертывания использовать материал в /usr/local/share/. Конечно, вы можете проверить еще больше мест (например, /usr/share).

По существу, для этого метода требуется наличие функции, которая создает правильные пути для всех обращений к файловой системе. Вместо fopen("data/blabla.conf", "w") используйте что-то вроде fopen(path("blabla.conf"), "w"). path () создаст правильный путь из пути, определенного с помощью тестов каталогов при запуске программы. Например. если путь был /usr/local/share/yourproject/data/, строка, возвращаемая path("blabla.conf"), была бы "/usr/local/share/yourproject/data/blabla.conf" - и это ваш хороший абсолютный путь.

Вот как бы я это сделал. НТН.