Установите временную среду ($ PATH)

С этим вопросом я могу столкнуться с проблемой X-Y, и я призываю вас, ребята, поправить меня, если я ошибаюсь.

Я хотел бы настроить среду набора инструментов, которая может работать на разных платформах и версиях компилятора. Первоначально я написал длинный Perl-скрипт, который генерирует конфигурационный Makefile, содержащий только переменные. Я хотел быть простым, поэтому я не писал ничего сложного, используя automake или autoconf. Более того, я хотел, чтобы процесс реконфигурации был очень быстрым. В моем случае мой собственный написанный ./configure делает все менее чем за секунду. Я очень доволен этим.

Однако я чувствую, что могу использовать лучший подход, используя переменные среды. Вместо того, чтобы писать Makefile с конкретными переменными, я могу установить текущую среду оболочки напрямую. Например:

export cc=gcc

К сожалению, некоторые переменные уже объявлены в $ PATH. Решение состоит в том, чтобы добавить новый $ PATH перед другим:

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

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

Я чувствую, что это некрасиво. Я хотел бы удалить старый путь перед добавлением нового.

Чтобы сделать вывод:

  1. Лучше использовать среду вместо пользовательских make файлов для установки конфигурации сборки?
  2. Как правильно настроить существующие переменные среды?

ОТВЕТЫ

Ответ 1

Когда у меня есть несколько переменных для установки, я пишу обертку script, которую затем использую в качестве префикса для команды, которую я хочу изменить. Это позволяет мне использовать префикс либо

  • применительно к одной команде, например make или
  • инициализация оболочки, так что последующие команды используют измененные настройки.

Я использую обертки для

  • задайте параметры компилятора (например, clang, чтобы установить переменную CC, создав скрипты configure "см." в качестве выбранного компилятора),
  • установка языковых переменных для тестирования с помощью POSIX C по сравнению с en_US по сравнению с en_US.UTF-8 и т.д.
  • тестирование с уменьшенной средой, например, в cron.

Каждая из оберток делает то, что необходимо для идентификации правильных PATH, LD_LIBRARY_PATH и подобных переменных.

Например, я написал этот ad hoc script около десяти лет назад для тестирования с локальной сборкой 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

и использовал его как with-python-2.4.2 myscript.

Некоторые обертки просто называют другой script. Например, я использую эту оболочку вокруг configure script для установки переменных для кросс-компиляции:

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

где choose-mingw32 и cfg-normal - это скрипты, которые (а) находят доступное имя цели для кросс-компилятора и (b) предоставляют дополнительные параметры configure script.

Другие могут предлагать псевдонимы или функции оболочки. Я не использую их для этой цели, потому что моя оболочка командной строки обычно tcsh, тогда как я запускаю эти команды из (а) других сценариев оболочки, (b) редактор каталогов или (c) текстовый редактор. Они используют оболочку POSIX (за исключением, конечно, для скриптов, требующих особых функций), делая псевдонимы или функции, которые мало используются.

Ответ 2

Вы можете создать индивидуальную среду для определенного вызова команды:

VAR1=val1 VAR2=val2 VAR3=val3 make

Я нахожу это чище, чем делать:

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

если вы не находитесь в обертке script и, возможно, даже тогда, как с VAR1=val1 VAR2=val2 VAR3=val3 make переменные VAR будут такими, какими они были до вызова make (включая, но не ограничиваясь, невыполненные и несуществующие).

Длинные строки не являются проблемой, вы всегда можете разбить ее на несколько строк:

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

Вы можете настроить переменные среды как это для любой команды Unix. Оболочка все это настроит. Некоторые приложения (например, make или rake) изменят свою среду на основе аргументов, которые выглядят как определения переменных (см. Ответ prodev_paris), но это зависит от приложения.

Ответ 3

Лучше ли использовать среду вместо пользовательских make файлов для настройки конфигурации сборки?

Лучшей практикой для систем построения является не зависящее от каких-либо переменных среды вообще. Чтобы ничего не было необходимо для создания вашего проекта, чем:

git clone ... my_project
make -C my_project

Необходимость установки переменных среды подвержена ошибкам и может привести к непоследовательным сборкам.

Как правильно настроить существующие переменные среды?

Возможно, вам не придется настраивать их вообще. Используя полные пути к инструментам, таким как компиляторы, вы отключите свою систему сборки из среды.

Ответ 4

Как мы все знаем, предпочтительнее интегрировать стандартные инструменты для задачи, например, для создания ваших продуктов, а не для создания собственного подхода. Усилия обычно окупаются в долгосрочной перспективе.

При этом простой подход состоял бы в том, чтобы определить различные файлы среды (например, build-phone.env), установив рабочий каталог, PATH, CC и т.д. для ваших разных продуктов, и интерактивно импортировать файлы среды по запросу:/p > 

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

Ответ 5

Я думаю, что вы можете использовать определение прямой переменной при вызове своего make файла, например, в следующем:

make FOO=bar target

Где FOO - это переменная, которую вы хотите установить со значением bar.

Обратите внимание, что в этом случае он имеет приоритет над определением среды! Таким образом, вы можете легко переопределить переменную PATH...

Пожалуйста, просмотрите эту тему подробно: fooobar.com/info/18771/...