Puede crear un entorno individualizado para la invocación de un comando en particular:
VAR1=val1 VAR2=val2 VAR3=val3 make
Encuentro esto más limpio que hacer:
export VAR1=val1
export VAR2=val2
export VAR3=val3
make
a menos que esté en un script de contenedor y tal vez incluso entonces como con VAR1=val1 VAR2=val2 VAR3=val3 make el VAR las variables serán lo que fueran antes de la invocación make (incluidas, entre otras, las no exportadas y las inexistentes).
Las líneas largas no son un problema, siempre puedes dividirlas en varias líneas:
VAR1=val1\
VAR2=val2\
VAR3=val3\
make
Puede configurar variables de entorno como esta para cualquier comando de Unix. El shell lo configurará todo. Algunas aplicaciones (como make o rake ) modificará su entorno en función de argumentos que parecen definiciones de variables (consulte la respuesta de prodev_paris), pero eso depende de la aplicación.
Como todos sabemos, es preferible integrar herramientas estándar para una tarea como la creación de sus productos en lugar de crear su propio enfoque. El esfuerzo suele dar sus frutos a largo plazo.
Dicho esto, un enfoque simple sería definir diferentes archivos de entorno (por ejemplo, build-phone.env ) configuración del directorio de trabajo, PATH , CC etc. para sus diferentes productos y fuente de archivos de su entorno de forma interactiva bajo demanda:
. /path/to/build-phone.env
[your build commands]
. /path/to/build-watch.env
[your build commands]
¿Es mejor usar el entorno en lugar de archivos MAKE personalizados para establecer una configuración de compilación?
La mejor práctica para construir sistemas es no depender de ninguna variable de entorno. Para que nada más sea necesario para construir tu proyecto que:
git clone ... my_project
make -C my_project
Tener que establecer variables de entorno es propenso a errores y puede generar compilaciones inconsistentes.
¿Cómo ajustar correctamente las variables de entorno existentes?
Es posible que no necesite ajustarlos en absoluto. Al usar rutas completas a herramientas como compiladores, desenreda su sistema de compilación del entorno.
Cuando tengo varias variables para configurar, escribo un envoltorio script que luego uso como prefijo del comando que quiero modificar. Eso me permite usar el prefijo
- aplicar a un solo comando, como
make, o - inicializando un shell, para que los comandos subsiguientes usen la configuración alterada.
Uso envoltorios para
- establecer las opciones del compilador (como
clang, para establecer elCCvariable, haciendo que los scripts de configuración "lo vean" como el compilador elegido), - estableciendo variables locales, para probar con POSIX
Ccontraen_UScontraen_US.UTF-8, etc. - probar con entornos reducidos, como en
cron.
Cada uno de los envoltorios hace lo necesario para identificar el PATH correcto , LD_LIBRARY_PATH y variables similares.
Por ejemplo, escribí este script ad hoc hace unos diez años para probarlo con una compilación local 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
y lo usé como with-python-2.4.2 miscript .
Algunos envoltorios simplemente llaman a otro script. Por ejemplo, uso este envoltorio alrededor del script de configuración para configurar variables para la compilación cruzada:
#!/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
donde choose-mingw32 y cfg-normal son scripts que (a) encuentran el nombre de destino disponible para el compilador cruzado y (b) brindan opciones adicionales al script de configuración.
Otros pueden sugerir shell alias o funciones . No los uso para este propósito porque mi shell de línea de comandos suele ser tcsh , mientras ejecuto estos comandos desde (a) otros scripts de shell, (b) editor de directorios o (c) editor de texto. Esos usan el shell POSIX (excepto, por supuesto, para scripts que requieren características específicas), haciendo que los alias o funciones sean de poca utilidad.