Как найти двоичные файлы во время проверки? - PullRequest
0 голосов
/ 10 января 2020

У меня проблемы с запуском make check из-за проблем с путями. В настоящее время мой сценарий оболочки (сконфигурированный autoconf) содержит

prefix="@prefix@"
exec_prefix="@exec_prefix@"
PATH="@libexecdir@:$PATH"

, позже он ожидает выполнения двоичного файла, расположенного в @ libexecdir@.. Этот поиск работает после make install, но когда он не работает, во время make check , Поскольку файлы еще не установлены, они не находятся в ожидаемом месте.

Какое правильное решение для этого? Я не должен быть первым, кто попытается решить эту проблему ...

Ответы [ 2 ]

2 голосов
/ 11 января 2020

Я не должен быть первым, кто попытается решить эту проблему.

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

Что такое правильное решение этого?

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

Наиболее общие формы такой гибкости, вероятно,

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

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

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

1 голос
/ 11 января 2020

Чтобы ответить на мой собственный вопрос, правильно сделать RTFM (как обычно):

Цитата (выделено мной): https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/autoconf.html#Installation -Directory-Variables

Большинство этих переменных имеют значения, основанные на префиксе или exec_prefix. Предполагается, что выходные переменные каталога сохраняют их нерасширенными: обычно «@ datarootdir @» заменяется на «$ {prefix} / share», а не «/ usr / local / share», а «@ datadir @» заменяется на « $ {datarootdir} '.

Это поведение предписано стандартами кодирования GNU, поэтому, когда пользователь запускает:

' make '

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

'make install'

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

Для поддержки этих функций важно, чтобы datarootdir оставался определенным как '$ {prefix} / share', чтобы его значение можно было расширить на основе текущего значения префикса.

Следствие заключается в том, что вы не должны использовать эти переменные, кроме как в make-файлах. Например, вместо того, чтобы пытаться оценить datadir в configure и жестко кодировать его в make-файлах, используя, например, 'AC_DEFINE_UNQUOTED ([DATADIR], ["$ datadir"], [Data directory.])', Вы должны добавить -DDATADIR = ' $ (datadir) 'к определению CPPFLAGS в вашем make-файле (AM_CPPFLAGS, если вы также используете Automake).

Аналогично, вам не следует полагаться на AC_CONFIG_FILES для замены bindir и друзей в сценариях оболочки и других файлах ; вместо этого пусть заставляют управлять их заменой. Например, Autoconf отправляет шаблоны своих сценариев оболочки, заканчивающиеся на «.in», и использует фрагмент make-файла, подобный следующему, для создания сценариев, таких как autoheader и autom4te:

 edit = sed \
         -e 's|@bindir[@]|$(bindir)|g' \
         -e 's|@pkgdatadir[@]|$(pkgdatadir)|g' \
         -e 's|@prefix[@]|$(prefix)|g'

 autoheader autom4te: Makefile
         rm -f $@ $@.tmp
         srcdir=''; \
           test -f ./$@.in || srcdir=$(srcdir)/; \
           $(edit) $${srcdir}$@.in >$@.tmp

         chmod +x $@.tmp
         chmod a-w $@.tmp
         mv $@.tmp $@

 autoheader: $(srcdir)/autoheader.in
 autom4te: $(srcdir)/autom4te.in
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...