Dlaczego config przyjmuje zmienne jako argumenty?

Czy to VAR=value ./configureto samo co ./configure VAR=value?

W pierwszym przypadku powłoka ustawia zmienną środowiskową, aw drugim skrypt konfiguracyjny bierze ciąg 'VAR=value'jako argument, a następnie przypuszczalnie ustawia zmienną. Zastanawiam się, czy config robi coś jeszcze ze zmienną (może ignoruje lub filtruje niektóre wartości) i dlaczego bierze zmienne jako argumenty.

W tym przypadku

VAR=value ./configure

zachowanie zależy od twojej bieżącej powłoki

./configure VAR=value

zachowanie zależy od skryptu konfiguracyjnego. Niektórzy programiści wolą to drugie, ponieważ chcieliby wybrać, czy ustawić zmienne w skrypcie, niż pozwolić komuś magicznie ustawić zmienne skryptu z zewnątrz.

W praktyce różnica jest niewielka, ponieważ

• większość osób wykonujących konfigurację korzysta z powłoki POSIX, gdzie poprzednie zachowanie „po prostu działa” i
• większość skryptów konfiguracyjnych nie wyłącza istniejących zmiennych środowiskowych, oraz
• konwencjonalne zmienne środowiskowe (poza automake) mają ugruntowane zastosowanie

Na przykład --helpkomunikat skryptu konfiguracji bash pokazuje to:

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.

i w każdym przypadku działa dowolny sposób ustawienia zmiennej .

Pamiętaj jednak o preferencjach programisty, na wypadek, gdyby ktoś zdecydował się na „ulepszenie” rzeczy.

Dalsza lektura:

• Przekazywanie zmiennych środowiskowych do autoconf,./configure
  które stwierdzają, że ta ostatnia (VAR = wartość) jest potrzebna do wprowadzenia wartościconfig.status
• 3.3 Zmienne środowiskowe
  omówione w ArgumentachAC_ARG_VAL , z punktu widzenia automake (i wyraża preferencje programisty):

AC_ARG_VARMakro służy do deklarowania konkretnego zmienną (środowisko) jako argument za scenariusz, nadając mu opis i szczególne zastosowanie. Chociaż ta funkcja została dodana stosunkowo niedawno w historii autoconf , jest bardzo ważna. Odzwierciedlając jego późniejszą obecność, makro nie potrzebuje AS_HELP_STRINGpomocnika i przyjmuje tylko dwa parametry: nazwę zmiennej i ciąg drukowany podczas ./configure --help:

AC_ARG_VAR(var-name, help-string)

i kontynuuje komentarz na temat długoletniej praktyki:

Domyślnie config odbiera zmienne ze środowiska, jak każdy inny skrypt sh. Większość z nich jest ignorowana. Te, które nie są, powinny być deklarowane za pomocą tego makra. W ten sposób są one oznaczone jako cenna zmienna.

Zmienna oznaczona jako szlachetna zostaje zastąpiona w Makefile.in bez konieczności wywoływania jawnego AC_SUBST, ale to nie jest najważniejsza część definicji. Ważne jest to, że zmienna jest buforowana.

• 7.2 Ustawienie zmiennych wyjściowych (dokumentacja autoconf)
  opisuje AC_ARG_VAR, ponownie wyrażając preferencje programisty:

  Wartość zmiennej podczas uruchamiania konfiguracji jest zapisywana w pamięci podręcznej, w tym jeśli nie została podana w wierszu poleceń, ale przez środowisko. Rzeczywiście, chociaż config może zauważyć definicję CC w „./configure CC = bizarre-cc”, nie można tego zauważyć w „CC = bizarre-cc ./configure”, co niestety robi większość użytkowników.