Чому конфігурація приймає змінні як аргументи?

Це VAR=value ./configureте саме, що ./configure VAR=value?

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

В цьому випадку

VAR=value ./configure

поведінка залежить від вашої поточної оболонки, перебуваючи в цьому

./configure VAR=value

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

На практиці різниці мало, тому що

• більшість людей, що здійснюють конфігурацію, працюють із оболонки POSIX, де колишня поведінка "просто працює" та
• більшість скриптів налаштування не скидає існуючі змінні середовища, і
• звичайні змінні середовища (поза автоматикою) мають давно встановлене використання

Наприклад, --helpповідомлення сценарію bash configure показує це:

Some influential environment variables:
  DEBUGGER_START_FILE
              location of bash debugger initialization file
  CC          C compiler command
  CFLAGS      C compiler flags
  LDFLAGS     linker flags, e.g. -L<lib dir> if you have libraries in a
              nonstandard directory <lib dir>
  LIBS        libraries to pass to the linker, e.g. -l<library>
  CPPFLAGS    C/C++/Objective C preprocessor flags, e.g. -I<include dir> if
              you have headers in a nonstandard directory <include dir>
  CPP         C preprocessor
  YACC        The `Yet Another C Compiler' implementation to use. Defaults to
              the first program found out of: `bison -y', `byacc', `yacc'.
  YFLAGS      The list of arguments that will be passed by default to $YACC.
              This script will default YFLAGS to the empty string to avoid a
              default value of `-d' given by some make applications.

і в кожному конкретному випадку, або спосіб установки змінних робіт .

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

Подальше читання:

• Передача змінних середовища в autoconf,./configure
  де зазначено, що остання (VAR = значення) потрібна для введення значенняconfig.status
• 3.3. Змінні середовища, як
  обговорюються аргументиAC_ARG_VAL , з точки зору автоматики (і виражає переваги розробника):

AC_ARG_VARМакрокоманда використовується , щоб оголосити конкретну (оточення) змінну в якості аргументу для сценарію, надаючи йому опис і конкретного використання. Хоча ця функція була додана порівняно недавно в історії autoconf , вона дійсно важлива. Відображаючи свою недавню присутність, макрос не потребує AS_HELP_STRINGпомічника, а бере лише два параметри: ім'я змінної та рядок, надруковані під час ./configure --help:

AC_ARG_VAR(var-name, help-string)

і продовжує коментар про багаторічну практику:

За замовчуванням налаштування вибирає змінні з оточення, як і будь-який інший скрипт sh. Більшість із них ігноруються. Ті, які не мають бути оголошені через цей макрос. Таким чином вони позначаються як дорогоцінна змінна.

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

• 7.2 Встановлення вихідних змінних (документація з автоконфігурацією)
  описує AC_ARG_VAR, знову висловлюючи переваги розробника:

  Значення змінної при запуску конфігурації зберігається в кеш-пам'яті, включаючи, якщо вона не була вказана в командному рядку, а через середовище. Дійсно, хоча налаштування може помітити визначення CC у "./configure CC = bizarre-cc", неможливо помітити це у "CC = bizarre-cc ./configure", що, на жаль, є тим, що робить більшість користувачів.