Ninja: Задокументируйте, как устанавливать переменные среды в подпроцессах.

Созданный на 9 авг. 2015  ·  10Комментарии  ·  Источник: ninja-build/ninja

Смотрите обсуждение на
https://groups.google.com/d/topic/ninja-build/ZGZ2Ewxsxaw/дискуссия
и предыдущая тема связана там.

Самый полезный комментарий

Будет ли проект заинтересован в PR, реализующем это? Это неприятный блокировщик ниже по течению для https://github.com/mesonbuild/meson/ , поскольку мы должны добавлять скрипты-оболочки для любой команды, которая требует установки переменных среды, которых постепенно становится довольно много.

Даже файлы проектов Makefile и Visual Studio поддерживают это, поэтому Ninja выделяется тем, что не поддерживает это. :)

Мы были бы рады реализовать это, если есть интерес к этой функции в Ninja.

Все 10 Комментарий

Читая это обсуждение, кажется, что переменные среды не поддерживаются в Ninja, потому что CreateProcess не поддерживает настройку PATH для поиска исполняемого файла для запуска при использовании lpCommandLine вместо lpApplicationName ? Дело в том, что execvpe и execle имеют одинаковое ограничение, поэтому я не понимаю, в чем здесь проблема.

Очень просто установить среду, наследуемую процессом на всех платформах, поэтому я хотел бы понять, что здесь блокирует. Ваше здоровье!

FWIW, мы бы действительно хорошо использовали эту функцию в Meson: https://github.com/mesonbuild/meson/issues/266 , https://github.com/mesonbuild/meson/issues/384 и т. д.

Будет ли проект заинтересован в PR, реализующем это? Это неприятный блокировщик ниже по течению для https://github.com/mesonbuild/meson/ , поскольку мы должны добавлять скрипты-оболочки для любой команды, которая требует установки переменных среды, которых постепенно становится довольно много.

Даже файлы проектов Makefile и Visual Studio поддерживают это, поэтому Ninja выделяется тем, что не поддерживает это. :)

Мы были бы рады реализовать это, если есть интерес к этой функции в Ninja.

На платформах POSIXy вы можете сделать

rule foo
  command = ENV1=env1 ENV2=env2 my_command

или

rule foo
  command = $env my_command
foo out: in
  env = ENV1=env1 ENV2=env2

Вам этого мало? Большинству команд не нужны env vars, и, как правило, поддержка меньшего количества вещей делает ниндзя простым.

Да, эта часть задокументирована , но Meson — это кроссплатформенная система сборки (предназначенная для обеспечения паритета функций на всех поддерживаемых платформах), и в настоящее время нам приходится использовать оболочки сценариев Python всякий раз, когда нам нужно установить переменные среды или иметь аргументы со специальными символами. (особенно новые строки).

Сначала мы также думали, что настройка env vars — это нишевый вариант использования, и откладывали, когда пользователи просили об этом, но на удивление большому количеству людей это нужно. Например, gobject-introspection в GNOME требует, чтобы вы установили CC / CXX /etc при вызове его инструментов, в противном случае он использует механизм автоматического обнаружения, который в конечном итоге использует неправильный компилятор. «Пользовательские цели» в Meson могут запускать произвольные команды, и люди часто спрашивают, как они могут устанавливать переменные среды при запуске какого-либо инструмента, поведение которого они не могут изменить.

Обходной путь сценария Python в порядке, но вызов интерпретатора Python для каждой команды иногда действительно замедляет работу.

Может быть, gobject-introspection может вместо этого принимать их через аргументы командной строки? (По моему опыту, сборки, которые полагаются на переменные окружения вместо флагов, как правило, гораздо более уязвимы для разработчиков, которые портят свои локальные окружения и т. д.)

MSVC cl.exe требует нескольких env vars для поиска включений и многого другого; для этого ниндзя есть ninja -t msvc -e , который может загружать среду из файла. Таким образом, meson теоретически может использовать это в Windows, а posix — в других местах.

Но использование оболочек python для редкого, «должно быть гибким» случая и обеспечение работы общих команд без зависимости от env кажется мне лучшим подходом.

Я думаю, что столкнулся с этой проблемой. Я пытаюсь создать исполняемый файл FIPS в окне, и мне нужно следовать этим указаниям:

https://www.openssl.org/docs/fips/UserGuide-2.0.pdf , раздел 5.3.2:

For the Windows®
 environment a perl script fipslink.pl is provided which performs a
function similar to fipsld for Unix®
/Linux®
. Several environment variables need to be set:
FIPS_LINK is the linker name, normally “link”
FIPS_CC is the C compiler name, normally “cl”
FIPS_CC_ARGS is a string of C compiler arguments for compiling fips_premain.c
PREMAIN_DSO_EXE should be set to the path to fips_premain_dso.exe if a DLL is
being linked (can be omitted otherwise)
PREMAIN_SHA1_EXE is the full path to fips_standalone_sha1.exe
FIPS_TARGET is the path of the target executable or DLL file

Несмотря на то, что FIPS_CC определен в моей среде, похоже, что ниндзя не передает env дочернему процессу ( perl fipslink.pl ... ). Я посмотрю, работает ли -e для меня.

Другой вариант использования для этого — установка LD_LIBRARY_PATH перед запуском исполняемых файлов, встроенных в проект. Это часто необходимо для исполняемых файлов, связанных с общими библиотеками, встроенными в проект, чтобы гарантировать, что уже существующие версии в пользовательском префиксе не используются ( -Wl,-rpath не работает в дистрибутивах, которые вместо этого устанавливают DT_RUNPATH из DT_RPATH , таких как Debian и Ubuntu). Autotools (libtool) использует для этого сценарии оболочки. Если бы нам пришлось запускать интерпретатор Python или запускать сценарий оболочки для таких случаев, сборка значительно замедлилась бы.

В качестве еще одной точки данных cmake настолько часто встречался с этим вариантом использования, что у них есть оболочка C для него, которая устанавливает среду, а затем вызывает процесс. Им в любом случае это нужно для их бэкэнда make, но системы сборки только для ниндзя очень выиграют от этой функции.

Я не совсем уверен, что эта ошибка обсуждается, поскольку похоже, что изначально речь шла об обновлении документации. :)

Для LD_LIBRARY_PATH установка через командную строку уже работает, как упоминал Нико выше. Это не включает другой процесс; мы все равно должны использовать оболочку для разбора командной строки. (Подпроцессы в Linux в любом случае очень дешевые; вы даже не можете измерить /bin/sh -c "echo hello" , потому что это так быстро.)

В Windows у нас есть ninja -t msvc . Вы можете попробовать написать свою функцию мезона, используя это, а затем, когда у нас будет некоторый опыт, мы сможем понять, как ее улучшить.

Kconfiglib имеет жесткое требование $srctree для сборок из исходных кодов. Он использует несколько других переменных:
https://github.com/ulfalizer/Kconfiglib/blob/424d0d38e7/kconfiglib.py#L108

в настоящее время нам приходится использовать оболочки сценариев Python всякий раз, когда нам нужно установить переменные среды.

Из: https://github.com/ulfalizer/Kconfiglib/tree/424d0d38e7be15c5#overview

Вся библиотека содержится в kconfiglib.py. Связанные скрипты реализованы поверх него. Внедрение собственных сценариев должно быть относительно простым, если это необходимо.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги