On Mon, 11 May 2026 at 09:37, Daniel P. Berrangé <[email protected]> wrote: > IIUC, the main reason to want binaries in a specific location is > so that tests find them in that location. That is a valid historical > approach, but meson offer an alternative approach that could be used > instead.
It's not the only reason, though. The other half is humans. People do run QEMU and the tools out of the build directory quite frequently, and so the location of the binaries in the build tree shouldn't have to depend on where we put the tool sources in the source tree or where we want to put the meson runes in the meson.build files. Just as we prefer to have qemu-system-foo in the top level of the build tree, I think it's also preferable to put the qemu-bar tools binaries there. It's more consistent, and they're easier to find. > We can set the test environment so that meson modifies $PATH such that > all the built binaries appear at head of $PATH. Tests then don't need > to assume a location for them in the build directory, just let execvp > search $PATH as normal. For execution outside of 'meson test', we have > "meson devenv" which sets up a local interactive shell environment, or > we can launch the test via the "run" script which wraps "meson devenv" > for a single command. I definitely don't want to have to run a separate command to set up an environment: this is painful whenever I have to interact with python venvs, and it's not something I think we want or need here. I think the least-worst option is that we say "all the meson runes for building executables must live in the top level meson.build even if the sources and most of the meson runes for the source/object files are in a subdirectory". thanks -- PMM
