Définir un environnement temporaire ($PATH)

Vous pouvez créer un environnement individualisé pour un appel de commande particulier :

VAR1=val1 VAR2=val2 VAR3=val3 make

Je trouve cela plus propre que de faire :

   export VAR1=val1
   export VAR2=val2
   export VAR3=val3
   make

sauf si vous êtes dans un script wrapper et peut-être même alors comme avec VAR1=val1 VAR2=val2 VAR3=val3 make le VAR les variables seront ce qu'elles étaient avant l'invocation de make (y compris, mais sans s'y limiter, non exportées et inexistantes).

Les longues lignes ne posent aucun problème, vous pouvez toujours les répartir sur plusieurs lignes :

VAR1=val1\
VAR2=val2\
VAR3=val3\
make

Vous pouvez configurer des variables d'environnement comme celle-ci pour n'importe quelle commande Unix. Le shell le configurera entièrement. Certaines applications (telles que make ou rake ) modifieront leur environnement en fonction d'arguments qui ressemblent à des définitions de variables (voir la réponse de prodev_paris), mais cela dépend de l'application.

Comme nous le savons tous, il est préférable d'intégrer des outils standards pour une tâche comme la construction de vos produits plutôt que de créer votre propre approche. L'effort est généralement payant à long terme.

Cela étant dit, une approche simple consisterait à définir différents fichiers d'environnement (par exemple, build-phone.env ) définition du répertoire de travail, PATH , CC etc. pour vos différents produits et sourcez vos fichiers d'environnement de manière interactive à la demande :

. /path/to/build-phone.env
[your build commands]
. /path/to/build-watch.env
[your build commands]

Est-il préférable d'utiliser l'environnement plutôt que des makefiles personnalisés pour définir une configuration de construction ?

La meilleure pratique pour les systèmes de construction est de ne dépendre d'aucune variable d'environnement. Pour que rien de plus ne soit nécessaire pour construire votre projet que :

git clone ... my_project
make -C my_project

Devoir définir des variables d'environnement est sujet aux erreurs et peut conduire à des versions incohérentes.

Comment ajuster correctement les variables d'environnement existantes ?

Vous n'aurez peut-être pas besoin de les ajuster du tout. En utilisant des chemins complets vers des outils tels que des compilateurs, vous démêlez votre système de construction de l'environnement.

Quand j'ai plusieurs variables à définir, j'écris un wrapper script que j'utilise ensuite comme préfixe de la commande que je veux modifier. Cela me permet d'utiliser le préfixe soit

• appliquer à une seule commande, telle que make , ou
• initialisation d'un shell, afin que les commandes suivantes utilisent les paramètres modifiés.

J'utilise des wrappers pour

• définir les options du compilateur (telles que clang , pour définir le CC variable, faisant en sorte que les scripts de configuration la "voient" comme le compilateur choisi),
• définition des variables locales, à tester avec POSIX C contre en_US contre en_US.UTF-8 , etc.
• tester avec des environnements réduits, comme dans cron .

Chacun des wrappers fait ce qui est nécessaire pour identifier le bon PATH , LD_LIBRARY_PATH , et variables similaires.

Par exemple, j'ai écrit ce script ad hoc il y a une dizaine d'années pour tester avec une version locale de python :

#!/bin/bash
ver=2.4.2
export TOP=/usr/local/python-$ver
export PATH=$TOP/bin:$PATH
export LD_LIBRARY_PATH=`newpath -n LD_LIBRARY_PATH -bd $TOP/lib $TOP/lib/gcc/i686-pc-linux-gnu/$ver`
if test -d $TOP
then
    exec $*
else
    echo no $TOP
    exit 1
fi

et l'a utilisé comme with-python-2.4.2 monscript .

Certains wrappers appellent simplement un autre script.Par exemple, j'utilise ce wrapper autour du script configure pour configurer les variables pour la compilation croisée :

#!/bin/sh
# $Id: cfg-mingw,v 1.7 2014/09/20 20:49:31 tom Exp $
# configure to cross-compile using mingw32

BUILD_CC=${CC:-gcc}
unset CC
unset CXX

TARGET=`choose-mingw32`

if test -n "$TARGET"
then
    PREFIX=
    test -d /usr/$TARGET && PREFIX="--prefix=/usr/$TARGET"
    cfg-normal \
            --with-build-cc=$BUILD_CC \
            --host=$TARGET \
            --target=$TARGET \
            $PREFIX "[email protected]"
else
    echo "? cannot find MinGW compiler in path"
    exit 1
fi

où choose-mingw32 et cfg-normal sont des scripts qui (a) trouvent le nom cible disponible pour le compilateur croisé et (b) fournissent des options supplémentaires au script de configuration.

D'autres peuvent suggérer des alias shell ou fonctions . Je ne les utilise pas à cette fin car mon shell de ligne de commande est généralement tcsh , pendant que j'exécute ces commandes à partir (a) d'autres scripts shell, (b) d'un éditeur de répertoires ou (c) d'un éditeur de texte. Ceux-ci utilisent le shell POSIX (sauf bien sûr, pour les scripts nécessitant des fonctionnalités spécifiques), faisant des alias ou des fonctions peu utiles.