Ninja: Agregue la opción de línea de comando ARGS para pasar argumentos al objetivo.

¿No puedes usar (cd $build_dir && ctest -R "FooTest") ? ¿Cuál es la ventaja de involucrar a un ninja?

Ups, no sabía que debajo de () no hay cambio de directorio. De todos modos, pensé que pasar cualquier ARGS adicional era una buena característica.

Genial, suena que se aborda su caso de uso, así que cerrando esto por ahora :-)

Con ninja efectivamente como el comando de interfaz para GN, sería útil tener un poco más de capacidad para pasar argumentos a los scripts, ya que haría las cosas útiles más simples y menos propensas a errores para los usuarios. Una forma más compacta serían los argumentos después de pasar a los scripts. Ejemplo:

ninja -C out / debug util / module: test && out / debug / module_test --gtest_filter = test1

con arg pasando:

ninja -C out / debug util / module: ejecutar - --gtest_filter = test1

También sería útil si ninja tuviera una forma de pasar la configuración -v .a los scripts.

Con ninja efectivamente como el comando frontal para GN,

No es una buena idea si desea muchas funciones y mejoras en la calidad de vida. Ninja es pequeño y bastante "de bajo nivel".

En cuanto a la prueba: en mi humilde opinión, es mucho más transparente si los argumentos de la prueba unitaria solo se pasan al ejecutor de la prueba, por ejemplo, usted llama al binario directamente usted mismo. Digamos que quieres terminar la llamada con vallgrind , ¿cómo harías eso con ninja? ¿O quiere ver su salida mientras se genera?

Lo que quiero decir es que un usuario de GN generalmente emite comandos de compilación reales a través de ninja, y se llama a GN según sea necesario para regenerar los archivos de compilación ninja cuando se modifican los archivos de compilación. No estoy pidiendo expandir el conjunto de funciones de ninja, solo estoy buscando un poco de utilidad con la capacidad de ninja para transmitir argumentos. Sí, tenga en cuenta que, en general, desea pasar argumentos directamente, pero también puedo ver mucha utilidad para simplificar las operaciones comunes para los usuarios.

Lo que quiero decir es que un usuario de GN generalmente emite comandos de compilación reales a través de ninja, y se llama a GN según sea necesario para regenerar los archivos de compilación ninja cuando se modifican los archivos de compilación.

Puede encadenar los comandos en Bash para que el binario esté siempre actualizado:

ninja -C out/debug && ./out/debug/theTestBinary --gtest_filter=test1

Sí, claro, pero el ninja ya conoce el camino hacia la prueba, por lo que puede ayudar a acortar el comando. El reenvío de argumentos solo abre un poco de flexibilidad adicional.

Ah, ya veo. Eso es realmente desafortunado, pero como el generador también lo sabe, creo que debería ser él quien proporcione los accesos directos / una interfaz. CMake hace esto con cmake --build y ctest , GN probablemente también debería hacerlo.

Con ninja efectivamente como comando frontal para GN

¿Qué es GN?

¿Qué es GN?
https://gn.googlesource.com/gn/

GN es el meta sistema de compilación de Chromium que apunta a los ninjas. Es un gran sistema de construcción, pero no muy conocido. Tomando tu ejemplo:

widget ninja -C out / debug

Como mencioné, GN hace que los ninjas hagan las compilaciones reales, y GN se llama según sea necesario cuando cambian las definiciones de compilación. Entonces, si ninja admite el reenvío de arg, podría resultar en un comando mucho más simple para los usuarios porque ninja ya tiene un directorio de salida (out / debug), el objetivo (widget: test) y también puede ejecutar la prueba si el reenvío fuera posible:

widget ninja -C out / debug

Otra opción es pasar por el entorno, como

rule whatever
  command = theTestBinary $$ARGS

y luego

$ ARGS="-foo bar" ninja ...

Esto también es más flexible ya que permite que el archivo de compilación (a través de ese command attr) controle dónde exactamente dentro del subcomando se usan los argumentos, cuál es su nombre, citando, etc.