Odd target ordering with generators and extracted objects

[mitchgrout]

This situation is best demonstrated with an MVP. Note that I am not suggesting that the following code is good, but instead results in an unexpected build.ninja file.

Suppose we have an external program named hexdump with the following syntax:

$ hexdump [INPUT-FILE] [OUTPUT-HEADER] [OUTPUT-SOURCE]

...with the intent of the program being to take an external file, e.g. image assets, and convert them into an array of bytes usable in your program (think #embed from C23). Suppose I also have a file named foo.bin that contains irrelevant data, and a main.c containing:

#include "foo.h"
int main(void) { return 0; }

The following would be a valid meson.build file:

project('wat', 'c')

hexdump    = find_program('hexdump')
hexdump    = generator(hexdump, arguments: ['@INPUT@', '@OUTPUT1@', '@OUTPUT2@'], output: ['@BASENAME@.h', '@BASENAME@.c'])
assets_lib = library('assets', hexdump.process('foo.bin'))
assets     = declare_dependency(link_with: assets_lib, include_directories: assets_lib.private_dir_include())

executable('main', 'main.c', dependencies: assets)

Looking at the build.ninja, we can extract the following build rules:

build libassets.a.p/foo.h libassets.a.p/foo.c: CUSTOM_COMMAND ../foo.bin | .././hexdump
build libassets.a.p/meson-generated_foo.c.obj: c_COMPILER libassets.a.p/foo.c || libassets.a.p/foo.h
build libassets.a: STATIC_LINKER libassets.a.p/meson-generated_foo.c.obj
build main.exe.p/main.c.obj: c_COMPILER ../main.c || libassets.a.p/foo.h
build main.exe: c_LINKER main.exe.p/main.c.obj | libassets.a

We can observe that main.c.obj must be compiled after libassets.a.p/foo.h is generated; this is necessary, since main.c refers to foo.h as in include. This build configuration will work OK.

Now consider adjusting our declared dependency to:

assets = declare_dependency(objects: assets_lib.extract_all_objects(), include_directories: assets_lib.private_dir_include())

In my eyes, this should be perfectly equivalent; the build.ninja disagrees:

build libassets.a.p/foo.h libassets.a.p/foo.c: CUSTOM_COMMAND ../foo.bin | .././hexdump
build libassets.a.p/meson-generated_foo.c.obj: c_COMPILER libassets.a.p/foo.c || libassets.a.p/foo.h
build libassets.a: STATIC_LINKER libassets.a.p/meson-generated_foo.c.obj
build main.exe.p/main.c.obj: c_COMPILER ../main.c
build main.exe: c_LINKER libassets.a.p/meson-generated_foo.c.obj main.exe.p/main.c.obj

Note that main.c.obj no longer depends on libassets.a.p/foo.h, and as such it is possible that ninja attempts to compile main.c before generating any of the headers, resulting in a compilation header due to a missing header.

I've reproduced this on meson v1.2.0 / ninja v1.11.1, on Windows 10. I'm not sure whether I would class this as a bug worth fixing, but it's definitely a bit of a surprise. I'm interested in whether the wider team is aware of this?