Add ARGS command line option to pass arguments to target.

[phcerdan]

Assuming a target called test, so we could do:

ninja test ARGS="-R FooTest"

Which would be symmetric to existing make usage.

make test ARGS="-R FooTest"

My use case is unit testing using ctest. I can use ctest directly in the build directory, and pass arguments to it.

ctest -R "FooTest"

But I would like to call those tests from elsewhere, so I was using:

make test -C $build_dir ARGS="-R FooTest"

But ninja doesn't have this feature.

[nico]

Can't you just use (cd $build_dir && ctest -R "FooTest")? What's the advantage of involving ninja?

[phcerdan]

Ups, I didn't know that under () there is not change of directory. Anyway, I thought that passing whatever extra ARGS was a nice feature.

[nico]

Cool, sounds your use case is addressed, so closing this out for now :-)

[cruisercoder]

With ninja effectively as the front end command for GN, it would be useful to have just a bit more capability in passing arguments to scripts as it would make useful things simpler and less error prone for users. A more compact form would be arguments after-- get passed to scripts. Example:

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

with arg passing:

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

It would also be useful if ninja had a way to pass the -v setting .to scripts.

[jhasse]

With ninja effectively as the front end command for GN,

That's not a good idea if you want lots of features and quality-of-life improvements. Ninja is small and rather "low-level".

As for the test: IMHO it's much more transparent if unit test arguments are only passed to the test runner, e.g. you call the binary directly yourself. Let's say you want to wrap the call with vallgrind, how would you do that with ninja? Or you want to see it's output while it's being generated?

[cruisercoder]

What I mean is that a GN user is generally issuing actual build commands through ninja, with GN being called as needed to regenerate ninja build files when build files are modified. I'm not asking to expand ninja's feature set, I'm just looking for a tiny bit of utility with ninja's ability to forward arguments. Yes, point taken that in general you want to pass arguments directly, but I can also see a lot of utility in making common operations simpler for users too.

[jhasse]

What I mean is that a GN user is generally issuing actual build commands through ninja, with GN being called as needed to regenerate ninja build files when build files are modified.

You can chain the commands in Bash so that the binary is always up-to-date:

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

[cruisercoder]

Yes of-coarse, but ninja already knows the path to the test so it can help make the command shorter. Argument forwarding just opens up some additional flexibility.

[jhasse]

Ah I see. That's unfortunate indeed, but as the generator also knows this, I think he should be the one who provides the shortcuts / a frontend. CMake does this with cmake --build and ctest, GN should probably too.

[phcerdan]

With ninja effectively as the front end command for GN

What is GN?

[metti]

What is GN?
https://gn.googlesource.com/gn/

[cruisercoder]

GN is the meta build system for Chromium that targets ninja. It's a great build system but not well known. Picking up on your example:

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

As I mentioned, GN has ninja do the actual builds, with GN being called as needed when build definitions change. So if ninja supported arg forwarding, it could result in a much simpler command for users because ninja already has output directory (out/debug), the target (widget:test), and can run the test as well if forwarding were possible:

ninja -C out/debug widget:test -- --gtest_filter=test1

[evmar]

Another option is to pass via the environment, like

rule whatever
  command = theTestBinary $$ARGS

and then

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

This is also more flexible as it allows the build file (via that command attr) to control where exactly within the subcommand the arguments are used, what their name is, quoting, etc.