Make the input globs of pixi build backends configurable

[Hofer-Julian]

Problem description

As pointed out on Discord, our backends only trigger a rebuild when certain files are touched. For example, for pixi-build-python it's the following list:

https://github.com/prefix-dev/pixi-build-backends/blob/6aa683e0b7212665af6d04b80227438a5ab4f43a/crates/pixi-build/src/bin/pixi-build-python/protocol.rs#L362

That is a sane default, but not applicable e.g. with maturin where you'd also want **/*.rs to be included. With meson-python every file type that is handled by meson should trigger a rebuild.

We should provide reasonable defaults, but then add an option so that users can adapt the input globs according to their needs.

[eli-schwartz]

With meson-python every file type that is handled by meson should trigger a rebuild.

There aren't really "filetypes" that can trigger a rebuild, but any build graph edge could trigger a rebuild if necessary. Maybe the most reliable way to determine this is to just directly ask ninja for that dynamic information.

• ninja -t inputs -- list all files that are an input for another file, including both e.g. *.c files as well as *.o files (because the latter are both outputs as well as inputs for *.so files, apparently)
• ninja -t graph -- output a graphviz dotfile of the build graph, in theory allows you to distinguish origin nodes from transitive nodes

[Hofer-Julian]

Maybe the most reliable way to determine this is to just directly ask ninja for that dynamic information.

That's a great idea, thanks @eli-schwartz

[baszalmstra]

I think this should be done on a per backend basis. For the CMake backend we can determine this by querying the cmake-file-api.

For the python backend we could add support for a few known backends and use workarounds there (for instance with meson).

[eli-schwartz]

Meson has a JSON file API too: https://mesonbuild.com/IDE-integration.html#the-targets-section

It's just not obvious to me that this is easier than querying ninja for this information. ;) I guess you could use it in the event that someone asks meson to use a non-default backend like xcode instead of ninja. I cannot think of why anyone would ever do this -- meson supports ninja, xcode, and msbuild, but the latter two are incredibly slow by design and have no advantages other than integrating with Microsoft / Apple IDEs.

[baszalmstra]

Cool! Yeah sounds like ninja is the way to go! Would you also recommend this route for the cmake backend (where we also always use ninja)?

[eli-schwartz]

IMO yes. It's much simpler to parse, at least.

[baszalmstra]

Does the output also include the cmake files? So that if you change a cmake file the build is also invalidated.

[eli-schwartz]

ninja -t inputs

will print out all inputs for the default target, usually ninja all. This does not include inputs that invalidate the build. To get inputs that invalidate the build, you want

ninja -t inputs build.ninja

Which does list all the meson.build or CMakeLists.txt / *.cmake files. Ninja handles regenerating itself based on build.ninja inputs implicitly, without putting it into the default target.

---

The meson IDE introspection equivalent of ninja -t inputs build.ninja is using the intro-buildsystem_files.json file, FWIW.