Builtin clang-tidy task cannot reliably run if generators or custom targets are used

[mitchgrout]

Carrying on from the situation in #12424 and #12425, because of the behaviour of custom_target and generator only triggering when a compilation is required, the builtin clang-tidy task will fail if the project is not compiled in advance. Example:

source.c

#include "header.h"

meson.build

project('fails', 'c')
header = custom_target(output: 'header.h', command: ['touch', '@OUTPUT@'])
lib = library('lib', 'source.c', header)

---

$ touch .clang-tidy # Does not need to be valid
$ meson setup build
$ ninja -C build clang-tidy
...
../source.c:1:10: error: 'header.h' file not found [clang-diagnostic-error]
    1 | #include "header.h"
      |          ^~~~~~~~~~
$ ninja -C build
$ ninja -C build clang-tidy
# No errors

---

The question I have is whether this is intended; the existence of generators hampers my ability to integrate custom linters into my project because:

1. generator.process and custom_target() targets cannot be 'forced' to be built outside of compiling a library
2. You cannot force that a library be built before invoking another custom target or generator since these do not accept a depends keyword

So if a header is being generated within a library, we cannot force it to exist before running a linter, leading to false positives within the lint output. Requiring that the entire project be independently built prior to running the linters is also a poor idea as the compilation phase may be expensive, while the lint phase cheap; I also don't want to force my CI job to build the project just so it can run a comparatively cheap lint phase. Thoughts on resolution?

[eli-schwartz]

generator.process and custom_target() targets cannot be 'forced' to be built outside of compiling a library

custom_target is a regular top-level ninja target with a return value that can be used as a dependency for any other target, or an alias_target.

Both custom targets and generator outputs have ninja build edges you can run, although generator targets are relatively well hidden inside the private directory of a given library target.

You cannot force that a library be built before invoking another custom target or generator since these do not accept a depends keyword

Can you elaborate?

• custom_target(depends: [...]) does exist.
• generator(depends: [...]) does as well, since 0.51.0 (which is fairly old by now)

[mitchgrout]

Ah, that's some egg on my face; they do appear to accept depends: which resolves the issue for invoking linters by hand

[eli-schwartz]

The question I have is whether this is intended; the existence of generators hampers my ability to integrate custom linters into my project because:

This seems like a natural consequence of using generated source files -- you cannot use other files that depend on the generated source files, without knowing to build them. And ninja is the thing that knows how to build them, so somehow, ninja has to be involved.

In the specific case of meson's builtin linter targets, I suppose it is plausible we could make them depend on all files that are a) generated, b) source files for a library/executable build target. This would be a special case within meson, but I guess that's the best we could even do.

[mitchgrout]

I feel as though the clang-tidy builtin linter would be better served as an optional module rather than being magic'd into your project.
That way, it could be set up to explicitly have these dependencies in mind rather than scanning for them globally, e.g.

tidy = import('clang-tidy')
tidy.configure(...files, depends: ...extra)

[eli-schwartz]

You could use a run_target() for this. Those accept depends: and allow you to specify a one-off command with no output (Makefile would call this a .PHONY command).

It's the same thing that meson magics in for you, except that meson's magic command is ['meson', '--internal', 'clangtidy'] which is a bit of helper glue that calculates which files to run on using git ls-files or a .clang-tidy-include if it exists.

If you're going to specify which files to run on anyway then there's no particular benefit to having meson wrap it for you. And if you define your own target called clang-tidy then meson won't try to generate its own (conflicting) one.

[mitchgrout]

In my project I'll likely be creating my own to get a bit more fine control over it, however the problem in general still exists; since the target magic'd into existence, we'd probably want meson to also magic in the correct dependencies to ensure all files are present; unfortunately I don't think you'd want to try to force only header generation, so it would be safer to just generate everything.

[eli-schwartz]

Off the top of my head I can't think of anything other than headers that would be needed.

Well, there is c23 #embed as well. However, from meson's perspective such files should still be treated as "header dependencies" (maybe better to say: order-only dependencies on a build target) that simply happen to have a file extension other than .h.