autoconf с использованием sh, мне нужно SHELL=BASH, как заставить autoconf использовать bash?

Question

Я запускаю autoconf и в настройках SHELL устанавливаю значение «/bin/sh».Это создает огромные проблемы.Как заставить SHELL быть «/bin/bash» для autoconf?

Я пытаюсь запустить это на OSX, на Linux оно работает.Linux использует SHELL=/bin/bash.osx по умолчанию — /bin/sh.

Answer 1

У меня аналогичные проблемы с GCC в Solaris, и я использую «стандартный» метод:

CONFIG_SHELL=/bin/bash ./configure ...

(Или, на самом деле, я использую /bin/ksh, но установка переменной env CONFIG_SHELL позволяет вам указать сценариям autoconf, какую оболочку использовать.)

Я проверил сценарий настройки для git и gd (они оказались извлечены), чтобы убедиться, что это не особая переменная окружения GCC.

Answer 2

В чем заключаются «огромные проблемы»?autoconf очень усердно работает над созданием сценария настройки, который работает с очень большим процентом оболочек.Если у вас есть пример конструкции, которую пишет autoconf и которая не является переносимой, сообщите об этом в список рассылки autoconf.С другой стороны, если проблемы, с которыми вы столкнулись, являются результатом того, что ваш собственный шелл-код в configure.ac не является переносимым (например, вы используете bashisms), тогда решение состоит в том, чтобы либо прекратить использование непереносимого кода, либо потребовать пользователь должен явно установить SHELL или CONFIG_SHELL во время настройки.

Похоже, проблема, с которой вы столкнулись, связана с средой пользователя, выполняющего настройку.В Linux для SHELL вашего пользователя установлено значение /bin/bash, но в OS X для него установлено значение /bin/sh.Сценарий настройки, сгенерированный autoconf, выполняет некоторые начальные тесты оболочки, под которой он работает, и пытается повторно запуститься с использованием другой оболочки, если в предоставленной оболочке отсутствуют определенные функции.Однако, если вы добавляете непереносимый шелл-код в configure.ac, вы нарушаете один из основных принципов autoconf, а именно то, что скрипты configure должны быть переносимыми.Если вы действительно хотите использовать bashisms в своем шелл-коде, вам необходимо, чтобы ваш пользователь передал SHELL=/bin/bash в качестве аргумента скрипту настройки.Это не ошибка в autoconf, но многие сочтут ее ошибкой в ​​сборке вашего проекта.

Answer 3

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

if test X$foo = X ; then ...   # check if foo is empty

скорее, чем:

if [ "$x" = "" ] ; then ...

Такой корявый код, вероятно, когда-то позволял этим сценариям запускаться в какой-нибудь древней системе Ultrix или где-то еще.

Сценарий конфигурации, который не запускается из-за различий в оболочках, — это все равно, что приехать на гонку Формулы-1 с 10 литрами бензина и тремя запасными шинами.

Если вы разрабатываете сценарий настройки с помощью Autoconf, и он чувствителен к тому, является ли оболочка Bash или оболочкой OSX, вы делаете что-то неправильно, или люди из Autoconf что-то сломали.Если это от вас, исправьте все части оболочки, которые вы добавляете в сценарий, сделав их переносимыми.

Answer 4

Где SHELL настроен на это?Что выполняется с /bin/sh, когда вам нужен /bin/bash?

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

Редактировать:в чем именно проблема?:

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

if test "$SHELL" = "/bin/sh" && test -x /bin/bash; then
    exec /bin/bash -c "$0" "$@"
fi

Answer 5

ln -f /bin/bash /bin/sh

:-P (Нет, это несерьёзный ответ.Пожалуйста, не засоряйте свою систему этим!)