Validity of using run_command for file generation

[mitchgrout]

As of meson v1.2.0, the following code fragment is valid:

project('testing', 'cpp')

run_command('touch', 'test.cpp')
library('testing', 'test.cpp')

Is this behaviour:

1. Intentional, and
2. Intended to be supported within the major 1 release?

I'm aware that custom_target and generator.process are the tools designed for code generation, but #2320 prevents me from realistically using them in a nontrivial .proto project.

[eli-schwartz]

Formally speaking, run_command() gives you great power.

And with great power, comes great responsibility.

Meson doesn't know the file was created via run_command. It has no way of knowing. It also has no way of responding to this information.

Meson will therefore behave as though it was created manually with a text editor before running meson setup. It assumes you will update it when you want it to be updated, and will return an inscrutable "error: no such file as test.cpp" if that run_command fails or does something you didn't expect.

Incidentally, it does do something you didn't expect. A run_command() is run in an unspecified directory.

[mitchgrout]

Restricting the discussion to my main target which is protoc, the unspecified directory is inconsequential since we have options to set input/output directories via --proto_path and --<lang>_out, which should work fine if meson.project_source_root() always returns an absolute directory.

The main thing I'm worried about is the build build.ninja: REGENERATE_BUILD task that gets set up, since the whole setup depends on this. If I had a run_command config like this:

run_command(
  'protoc', '--proto_path=...', '--cpp_out=...',
  'relative/path/to/my.proto', ...
)

...then meson is willing to recognize that relative/path/to/my.proto is indeed a valid path, and includes it in the dependency list for the REGENERATE_BUILD task. This feels like an intended behaviour, but I'm wanting to be sure since if my .proto's don't show up in this list, then my codegen will not trigger again.

[eli-schwartz]

Meson will attempt to add run_command() arguments that are existing files as additional rules for re-running meson --internal regenerate.

[mitchgrout]

Will note for anyone who reads this and thinks to use this setup, the main downsides IMO are:

1. Updating your meson.build file will trigger a re-run of the run_command, and likely trigger unnecessary recompilation due to your sources being regenerated
2. Updating any of the input files will trigger a regeneration of all of them
3. It is not possible to mark things like options files as dependencies unless specified within the run_command in a way that meson will detect

[eli-schwartz]

but #2320 prevents me from realistically using them in a nontrivial .proto project.

Incidentally this is expected to change. I will be very happy to stop having to discuss various... replacements... with people. :D