Pourquoi configure prend-il des variables comme arguments?

Est-ce VAR=value ./configurela même chose que ./configure VAR=value?

Dans le premier cas, le shell définit la variable d'environnement et dans le second, le script configure prend la chaîne 'VAR=value'en argument, puis définit vraisemblablement la variable. Je me demande si configure fait autre chose avec la variable (peut-être ignorer ou filtrer certaines valeurs), et pourquoi il prend les variables comme arguments en premier lieu.

Dans ce cas

VAR=value ./configure

le comportement dépend de votre shell actuel, alors que dans ce

./configure VAR=value

le comportement dépend du script de configuration. Certains développeurs préfèrent ce dernier car ils aimeraient choisir de définir des variables dans le script, plutôt que d'avoir quelqu'un comme par magie pour définir les variables du script de l'extérieur.

En pratique, il y a peu de différence car

• la plupart des gens qui font la configuration s'exécutent à partir d'un shell POSIX, où l'ancien comportement "fonctionne juste", et
• la plupart des scripts de configuration ne suppriment pas les variables d'environnement existantes, et
• les variables d'environnement conventionnelles (hors automake) ont une utilisation établie de longue date

Par exemple, le --helpmessage du script bash configure montre ceci:

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.

et dans chaque cas, l'une ou l'autre manière de placer la variable fonctionne .

Mais gardez à l'esprit les préférences du développeur, au cas où quelqu'un déciderait "d'améliorer" les choses.

Lectures complémentaires:

• Passer des variables d'environnement à autoconf./configure
  qui indique que cette dernière (VAR = valeur) est nécessaire pour mettre la valeur dansconfig.status
• 3.3. Variables d'environnement comme
  discute les argumentsAC_ARG_VAL , du point de vue d'automake (et exprime les préférences du développeur):

La AC_ARG_VARmacro est utilisée pour déclarer une variable (d'environnement) particulière comme argument pour le script, en lui donnant une description et une utilisation particulière. Bien que cette fonctionnalité ait été ajoutée relativement récemment dans l'histoire de la configuration automatique , elle est vraiment importante. Reflétant sa présence plus récente, la macro n'a pas besoin de l' AS_HELP_STRINGaide, et ne prend que deux paramètres: le nom de la variable et la chaîne imprimée pendant ./configure --help:

AC_ARG_VAR(var-name, help-string)

et continue avec un commentaire sur la pratique de longue date:

Par défaut, configure récupère les variables de l'environnement comme tout autre script sh. La plupart d'entre eux sont ignorés. Ceux qui ne le sont pas doivent être déclarés via cette macro. De cette façon, ils sont marqués comme une variable précieuse.

Une variable marquée comme précieuse est remplacée dans le Makefile.in sans avoir à appeler un explicite AC_SUBST, mais ce n'est pas la partie la plus importante de la définition. Ce qui est important, c'est que la variable soit mise en cache.

• 7.2 Définition des variables de sortie (documentation autoconf)
  décrit AC_ARG_VAR, exprimant à nouveau les préférences du développeur:

  La valeur de variable lors du lancement de configure est enregistrée dans le cache, y compris si elle n'a pas été spécifiée sur la ligne de commande mais via l'environnement. En effet, alors que configure peut remarquer la définition de CC dans './configure CC = bizarre-cc', il est impossible de la remarquer dans 'CC = bizarre-cc ./configure', ce que malheureusement la plupart des utilisateurs font.