Ustaw tymczasowe środowisko ($ PATH)

Question

Mogę popaść w problem X-Y z tym pytaniem i zachęcam was do poprawienia mnie, jeśli się mylę.

Chciałbym skonfigurować środowisko toolchain, które może działać na różnych platformach i różnych wersjach kompilatora. Początkowo napisałem długi skrypt Perla, który generuje konfigurację Makefile, która zawiera tylko zmienne. Chciałem być KISS, więc nie pisałem żadnych skomplikowanych rzeczy za pomocą automake lub autoconf. Ponadto chciałem, aby proces zmiany konfiguracji był bardzo szybki. W moim przypadku mój dom zrobił ./configure robi wszystko w czasie krótszym niż 1 sekunda. Jestem z tego bardzo szczęśliwy.

Jednak mogę wypełnić I można użyć lepszego podejścia przy użyciu zmiennych środowiskowych. Zamiast pisać plik Makefile z określonymi zmiennymi, mogę bezpośrednio ustawić bieżące środowisko powłoki. Na przykład:

export cc=gcc 

Niestety niektóre zmienne są już zadeklarowane w zmiennej $ PATH. Rozwiązaniem jest dodanie nowego $ PATH w przedniej części drugiej:

export PATH=/new/toolchain/path:$PATH 

echo $PATH 
/new/toolchain/path:/old/toolchain/path:/usr/bin:/bin... 

wypełnić ten jest brzydki Chciałbym usunąć starą ścieżkę przed dodaniem nowego.

Podsumowując:

1. Czy lepiej użyć środowiska zamiast niestandardowych makefile ustawić konfigurację budować?
2. Jak właściwie dostosować istniejące zmienne środowiskowe?

Answer 1

Gdy mam kilka zmiennych do ustawienia, piszę skrypt wrapper, który następnie używam jako przedrostek do polecenia, które chcę zmodyfikować. Że pozwala mi używać prefiksu albo

• zastosowanie do jednego polecenia, takie jak make lub
• inicjowanie powłokę, dzięki czemu kolejne polecenia użyć zmienione ustawienia.

używam obwoluty dla

• opcje ustawień kompilatora (takie jak clang, aby ustawić zmienną CC, dzięki czemu konfigurowanie skryptów „widzi” go jako wybranego kompilatora),
• ustawienie zmiennych lokalizacyjnych, przetestować z POSIX C w porównaniu z en_US w porównaniu z en_US.UTF-8, itp.
• testowanie w środowisku o obniżonej jakości, na przykład w cron.

Każda z owijarek wykonuje to, co jest potrzebne do zidentyfikowania właściwej zmiennej PATH, LD_LIBRARY_PATH i podobnych.

Na przykład, napisałem skrypt ad hoc około dziesięć lat temu do testowania z lokalnym kompilacji 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 

i używali go jako with-python-2.4.2myscript.

Niektóre opakowania po prostu wywołują inny skrypt. Na przykład, używam tego otoki wokół skryptu configure do zmiennych konfiguracyjnych do cross-kompilacji:

#!/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 "$@" 
else 
    echo "? cannot find MinGW compiler in path" 
    exit 1 
fi 

gdzie choose-mingw32 i cfg-normal są skrypty, które (a) znaleźć dostępną nazwę docelową dla cross-kompilatora oraz (b) zapewniają dodatkowe opcje skryptu konfiguracyjnego.

Inne mogą sugerować powłoki aliasy lub funkcji. Nie używam ich w tym celu, ponieważ moja linia poleceń jest zwykle tcsh, podczas gdy ja uruchamiam te komendy z (a) innych skryptów powłoki, (b) directory editor lub (c) text-editor. Te używają powłoki POSIX (z wyjątkiem oczywiście skryptów wymagających określonych funkcji), tworząc aliasy lub funkcje o małym wykorzystaniu.

Answer 2

myślę, można skorzystać z systemu bezpośredniej definicji zmiennej kiedy zadzwonić do makefile, jak w poniższym przykładzie:

make FOO=bar target 

Gdzie FOO jest zmienną, którą chcesz ustawić z wartością bar.

Należy pamiętać, że w tym przypadku ma on pierwszeństwo przed definicją środowiska! Dzięki czemu można łatwo zastąpić zmienną PATH ...

Proszę spojrzeć na ten szczegół temacie o więcej informacji: https://stackoverflow.com/a/2826178/4716013

Answer 3

lepiej jest użyć środowiska zamiast niestandardowych makefile ustawić konfigurację kompilacji ?

Najlepszą praktyką w systemach kompilacji jest brak zależności od zmiennych środowiskowych. Tak, że nic więcej trzeba budować swój projekt niż:

git clone ... my_project 
make -C my_project 

konieczności ustawiania zmiennych środowiskowych jest podatny na błędy i może prowadzić do niespójne buduje.

Jak właściwie dostosować istniejące zmienne środowiskowe?

Może nie być konieczne ich dostosowanie. Używając kompletnych ścieżek do narzędzi, takich jak kompilatory, rozplątujesz swój system kompilacji ze środowiska.

Answer 4

Jak wszyscy wiemy, lepiej jest zintegrować standardowe narzędzia do zadań takich jak tworzenie produktów, zamiast tworzyć własne. Wysiłek zazwyczaj się opłaca w dłuższej perspektywie.

Zgodnie z powyższym, prostym sposobem byłoby zdefiniowanie różnych plików środowiska (na przykład build-phone.env) ustawień katalogu roboczego, PATH, CC itd.dla różnych produktów i źródła pliki środowisko interaktywnie na żądanie:

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

Answer 5

można tworzyć zindywidualizowane środowiska dla konkretnego polecenia inwokacji:

VAR1=val1 VAR2=val2 VAR3=val3 make 

Uważam to czystsze niż robi:

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

, chyba że jesteś w skrypcie opakowania, a może nawet wtedy, jak w przypadku VAR1=val1 VAR2=val2 VAR3=val3 makeVAR var iabły będą takie same jak przed inwokacją wywołującą (w tym, ale nie wyłącznie, nieodnotowaną i nieistniejącą).

Długie kolejki to nie problem, zawsze można podzielić ją na kilka linii:

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

Można ustawić zmienne środowiskowe, jak to dla każdego polecenia Unix. Powłoka wszystko ustawi. Niektóre aplikacje (takie jak make lub rake) zmodyfikują swoje środowisko na podstawie argumentów, które wyglądają jak definicje zmiennych (patrz odpowiedź prodev_paris), ale zależy to od aplikacji.