On 5/11/2026 2:27 AM, Peter Maydell wrote: > 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 agree, this kind of "source my_env" are really not convenient to work with. Better to have things in the correct place instead. > 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". > Which is the way meson devs expect you to write it. For people looking for the definition of those executable, they can expect, without any surprise, that definition will be in top level meson.build. >From there, it's easy to see which sources var it uses and where it's declared. > thanks > -- PMM
