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 --help
message 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:
La AC_ARG_VAR
macro 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_STRING
aide, 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.
env VAR=value ./configure
relation avecVAR=value ./configure