Imposta un ambiente temporaneo ($PATH)

Puoi creare un ambiente personalizzato per una particolare invocazione di comando:

VAR1=val1 VAR2=val2 VAR3=val3 make

Lo trovo più pulito che fare:

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

a meno che tu non sia in uno script wrapper e forse anche allora come conVAR1=val1 VAR2=val2 VAR3=val3 make il VAR le variabili saranno ciò che erano prima dell'invocazione di make (incluse, a titolo esemplificativo ma non esaustivo, non esportate e inesistenti).

Le lunghe code non sono un problema, puoi sempre suddividerle su più righe:

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

Puoi impostare variabili di ambiente come questa per qualsiasi comando Unix. La shell lo imposterà. Alcune applicazioni (come make o rake ) modificheranno il loro ambiente in base ad argomenti che assomigliano a definizioni di variabili (vedi la risposta di prodev_paris), ma ciò dipende dall'applicazione.

Come tutti sappiamo, è preferibile integrare strumenti standard per un'attività come costruire i tuoi prodotti invece di creare il tuo approccio. Lo sforzo di solito ripaga a lungo termine.

Detto questo, un approccio semplice sarebbe quello di definire diversi file di ambiente (ad esempio build-phone.env ) impostazione della directory di lavoro, PATH , CC ecc. per i tuoi diversi prodotti e crea i tuoi file di ambiente in modo interattivo su richiesta:

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

È meglio usare l'ambiente invece di makefile personalizzati per impostare una configurazione di compilazione?

La migliore pratica per i sistemi di compilazione è non dipendere affatto da alcuna variabile di ambiente. In modo che per costruire il tuo progetto non sia necessario altro che:

git clone ... my_project
make -C my_project

Dover impostare variabili di ambiente è soggetto a errori e può portare a build incoerenti.

Come regolare correttamente le variabili di ambiente esistenti?

Potrebbe non essere necessario modificarli affatto. Utilizzando percorsi completi per strumenti come i compilatori, districhi il tuo sistema di compilazione dall'ambiente.

Quando ho diverse variabili da impostare, scrivo un wrapper script che poi utilizzo come prefisso al comando che voglio modificare. Questo mi permette anche di usare il prefisso

• applicata a un singolo comando, come make o
• inizializzazione di una shell, in modo che i comandi successivi utilizzino le impostazioni modificate.

Uso i wrapper per

• impostare le opzioni del compilatore (come clang , per impostare il CC variabile, facendo in modo che gli script di configurazione la "vedano" come il compilatore scelto),
• impostazione delle variabili locali, da testare con POSIX C contro en_US contro en_US.UTF-8 , ecc.
• test con ambienti ridotti, come in cron .

Ognuno dei wrapper fa ciò che è necessario per identificare il corretto PATH , LD_LIBRARY_PATH , e variabili simili.

Ad esempio, ho scritto questo script ad hoc circa dieci anni fa per testare con una build locale di 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

e l'ho usato come with-python-2.4.2 mioscript .

Alcuni wrapper chiamano semplicemente un altro script. Ad esempio, utilizzo questo wrapper attorno allo script configure per impostare le variabili per la compilazione incrociata:

#!/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

dove choose-mingw32 e cfg-normal sono script che (a) trovano il nome di destinazione disponibile per il cross-compilatore e (b) forniscono opzioni aggiuntive allo script configure.

Altri potrebbero suggerire alias di shell o funzioni . Non li uso per questo scopo perché la mia shell della riga di comando è solitamente tcsh , mentre eseguo questi comandi da (a) altri script di shell, (b) editor di directory o (c) editor di testo. Quelli usano la shell POSIX (tranne ovviamente per gli script che richiedono funzionalità specifiche), creando alias o funzioni di scarsa utilità.