Sie können eine individualisierte Umgebung für einen bestimmten Befehlsaufruf erstellen:
VAR1=val1 VAR2=val2 VAR3=val3 make
Ich finde das sauberer als Folgendes zu tun:
export VAR1=val1
export VAR2=val2
export VAR3=val3
make
es sei denn, Sie befinden sich in einem Wrapper-Skript und vielleicht sogar dann wie bei VAR1=val1 VAR2=val2 VAR3=val3 make die VAR Variablen sind so, wie sie vor dem make-Aufruf waren (einschließlich, aber nicht beschränkt auf, nicht exportiert und nicht vorhanden).
Lange Zeilen sind kein Problem, Sie können es jederzeit auf mehrere Zeilen aufteilen:
VAR1=val1\
VAR2=val2\
VAR3=val3\
make
Sie können Umgebungsvariablen wie diese für jeden Unix-Befehl einrichten. Die Shell wird alles einrichten. Einige Anwendungen (wie make oder rake ) ändern ihre Umgebung basierend auf Argumenten, die wie Variablendefinitionen aussehen (siehe die Antwort von prodev_paris), aber das hängt von der Anwendung ab.
Wie wir alle wissen, ist es vorzuziehen, Standardtools für eine Aufgabe wie die Erstellung Ihrer Produkte zu integrieren, anstatt einen eigenen Ansatz zu entwickeln. Der Aufwand zahlt sich in der Regel langfristig aus.
Davon abgesehen wäre ein einfacher Ansatz, verschiedene Umgebungsdateien zu definieren (z. B. build-phone.env ) Arbeitsverzeichnis einstellen, PATH , CC usw. für Ihre verschiedenen Produkte und beziehen Sie Ihre Umgebungsdateien interaktiv bei Bedarf:
. /path/to/build-phone.env
[your build commands]
. /path/to/build-watch.env
[your build commands]
Ist es besser, die Umgebung anstelle von benutzerdefinierten Makefiles zu verwenden, um eine Build-Konfiguration festzulegen?
Die beste Vorgehensweise für Build-Systeme besteht darin, überhaupt nicht von Umgebungsvariablen abhängig zu sein. Damit zum Erstellen Ihres Projekts nichts weiter erforderlich ist als:
git clone ... my_project
make -C my_project
Das Setzen von Umgebungsvariablen ist fehleranfällig und kann zu inkonsistenten Builds führen.
Wie passt man vorhandene Umgebungsvariablen richtig an?
Möglicherweise müssen Sie diese überhaupt nicht anpassen. Indem Sie vollständige Pfade zu Tools wie Compilern verwenden, entwirren Sie Ihr Build-System von der Umgebung.
Wenn ich mehrere Variablen setzen muss, schreibe ich einen Wrapper Skript, das ich dann als Präfix für den Befehl verwende, den ich ändern möchte. Dadurch kann ich entweder das Präfix
verwenden- Anwendung auf einen einzelnen Befehl, wie
make, oder - Eine Shell initialisieren, damit nachfolgende Befehle die geänderten Einstellungen verwenden.
Ich verwende Wrapper für
- Setzen von Compiler-Optionen (wie
clang, um denCCeinzustellen -Variable, sodass Konfigurationsskripte sie als ausgewählten Compiler „sehen“, - Locale-Variablen setzen, um mit POSIX
Czu testen gegenüberen_USgegenüberen_US.UTF-8usw. - Testen mit reduzierten Umgebungen, wie in
cron.
Jeder der Wrapper tut, was nötig ist, um den richtigen PATH zu identifizieren , LD_LIBRARY_PATH , und ähnliche Variablen.
Zum Beispiel habe ich dieses Ad-hoc-Skript vor etwa zehn Jahren geschrieben, um es mit einem lokalen Python-Build zu testen:
#!/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
und verwendet es als with-python-2.4.2 myscript .
Einige Wrapper rufen einfach ein anderes Skript auf. Zum Beispiel verwende ich diesen Wrapper um das configure-Skript herum, um Variablen für die Cross-Kompilierung einzurichten:
#!/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
wobei choose-mingw32 und cfg-normal sind Skripte, die (a) den verfügbaren Zielnamen für den Cross-Compiler finden und (b) zusätzliche Optionen für das Konfigurationsskript bereitstellen.
Andere können Shell-Aliase vorschlagen oder Funktionen . Ich verwende diese nicht für diesen Zweck, da meine Befehlszeilen-Shell normalerweise tcsh ist , während ich diese Befehle von (a) anderen Shell-Skripten, (b) dem Verzeichnis-Editor oder (c) dem Texteditor aus ausführe. Diese verwenden die POSIX-Shell (außer natürlich für Skripte, die bestimmte Eigenschaften erfordern) und machen Aliase oder Funktionen von geringem Nutzen.