Ninja: Documentar cómo establecer variables de entorno en subprocesos

Al leer esa discusión, parece que las variables de entorno no son compatibles con Ninja porque CreateProcess no admite la configuración PATH para encontrar el ejecutable para ejecutar cuando se usa lpCommandLine en lugar de lpApplicationName ? La cuestión es que execvpe y execle tienen la misma restricción, por lo que no entiendo cuál es el problema aquí.

Es realmente simple configurar el entorno heredado por un proceso en todas las plataformas, por lo que me gustaría entender cuál es el bloqueador aquí. ¡Salud!

FWIW, realmente haríamos un buen uso de esta función en Meson: https://github.com/mesonbuild/meson/issues/266 , https://github.com/mesonbuild/meson/issues/384 , etc.

¿El proyecto estaría interesado en un RP que implemente esto? Es un bloqueador problemático aguas abajo para https://github.com/mesonbuild/meson/ ya que tenemos que agregar secuencias de comandos de contenedor para cualquier comando que necesite establecer variables de entorno, que poco a poco se están convirtiendo en bastantes.

Incluso los archivos de proyecto Makefiles y Visual Studio admiten esto, por lo que Ninja se destaca por no admitirlo. :)

Sin embargo, estaremos encantados de implementar esto si hay interés en tener esta función en Ninja.

En las plataformas POSIXy, puede hacer

rule foo
  command = ENV1=env1 ENV2=env2 my_command

o

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

¿Eso no es suficiente para ti? La mayoría de los comandos no deberían necesitar env vars y, en general, admitir menos cosas hace que ninja sea simple.

Sí, esa parte está documentada , pero Meson es un sistema de compilación multiplataforma (destinado a tener paridad de características en todas las plataformas compatibles) y actualmente tenemos que usar envoltorios de secuencias de comandos de Python cada vez que necesitamos establecer variables de entorno o tener argumentos con caracteres especiales. (especialmente líneas nuevas).

Al principio, también pensamos que configurar env vars es un caso de uso de nicho y lo rechazamos cuando los usuarios lo solicitaron, pero sorprendentemente una gran cantidad de personas lo necesitan. Por ejemplo, gobject-introspection en GNOME requiere que configure CC / CXX /etc mientras invoca sus herramientas, de lo contrario, utiliza un mecanismo de detección automática que termina usando el compilador incorrecto. Los "objetivos personalizados" en Meson pueden ejecutar comandos arbitrarios, y las personas a menudo aparecen preguntando cómo pueden establecer variables de entorno mientras ejecutan alguna herramienta cuyo comportamiento no pueden cambiar.

La solución del script de Python está bien, pero invocar el intérprete de Python para cada comando realmente ralentiza las cosas a veces.

¿Tal vez gobject-introspection podría aceptarlos a través de argumentos de línea de comando? (En mi experiencia, las compilaciones que se basan en variables de entorno en lugar de banderas tienden a ser mucho más vulnerables a que los desarrolladores arruinen su entorno local, etc.)

cl.exe de MSVC requiere algunos env vars para encontrar incluye y otras cosas; porque ese ninja tiene ninja -t msvc que tiene un indicador -e que puede cargar un entorno desde un archivo. Entonces, mesón teóricamente podría usar eso en Windows, y las cosas posix en otros lugares.

Pero usar envoltorios de python para el caso raro, "debe ser flexible" y hacer que los comandos comunes funcionen sin depender de env parece ser el mejor enfoque para mí.

Creo que me he encontrado con este problema. Estoy tratando de construir un ejecutable FIPS en la ventana y necesito seguir estas instrucciones:

https://www.openssl.org/docs/fips/UserGuide-2.0.pdf , sección 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

Aunque FIPS_CC está definido en mi entorno, parece que ninja no está pasando el env al proceso secundario ( perl fipslink.pl ... ). Voy a ver si -e funciona para mí.

Otro caso de uso para esto es configurar LD_LIBRARY_PATH antes de ejecutar los ejecutables creados en el proyecto. Esto suele ser necesario con ejecutables vinculados a bibliotecas compartidas integradas en el proyecto para garantizar que no se utilicen versiones ya existentes en un prefijo personalizado ( -Wl,-rpath no funciona en distribuciones que configuran DT_RUNPATH en su lugar de DT_RPATH como Debian y Ubuntu). Autotools (libtool) usa scripts de shell para esto. Sería una ralentización significativa de la compilación si tuviéramos que generar un intérprete de Python o ejecutar un script de shell para tales casos.

Como otro punto de datos, cmake encontró tanto este caso de uso que tienen un envoltorio C para él que configura el entorno y luego llama al proceso. Lo necesitan de todos modos para su backend de creación, pero los sistemas de compilación exclusivos para ninjas se beneficiarían enormemente de esta función.

Ya no estoy seguro de qué está discutiendo este error, ya que parece que originalmente se trataba de actualizar los documentos. :)

Para LD_LIBRARY_PATH , configurarlo a través de la línea de comando ya funciona como Nico mencionó anteriormente. No involucra otro proceso; debemos usar un shell para analizar la línea de comando de todos modos. (Los subprocesos en Linux son muy baratos de todos modos; ni siquiera puedes medir /bin/sh -c "echo hello" porque es muy rápido).

En Windows tenemos ninja -t msvc . Puede intentar escribir su característica de mesón usando eso y luego, una vez que tengamos algo de experiencia con eso, podríamos descubrir cómo mejorarlo.

Kconfiglib tiene un requisito estricto de $srctree para compilaciones fuera de la fuente. Utiliza algunas otras variables:
https://github.com/ulfalizer/Kconfiglib/blob/424d0d38e7/kconfiglib.py#L108

actualmente tenemos que usar envoltorios de secuencias de comandos de Python cada vez que necesitamos establecer variables de entorno

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

La biblioteca completa está contenida en kconfiglib.py. Los scripts incluidos se implementan encima. La implementación de sus propios scripts debería ser relativamente fácil, si es necesario.