On Mon, May 11, 2026 at 12:23:32AM +0400, Marc-André Lureau wrote: > Hi > > On Fri, May 8, 2026 at 8:23 PM Peter Maydell <[email protected]> wrote: > > > > On Fri, 8 May 2026 at 17:00, Pierrick Bouvier > > <[email protected]> wrote: > > > > > > On 5/8/2026 8:24 AM, Peter Maydell wrote: > > > > We have a set of binaries that we call "tools": they're built based on > > > > the --enable-tools/--disable-tools configure setting, they're > > > > documented in docs/tools, and they're standalone executables of one > > > > form or another. > > > > > > > > Currently the sources for these are a bit scattered: many still in the > > > > top level source directory, some in contrib, one or two actually in > > > > the tools directory. > > > > > > > > As an initial attempt at cleanup, this patchset moves the sources for > > > > qemu-bridge-helper, qemu-edid, qemu-img, qemu-io, qemu-nbd, > > > > qemu-keymap, qemu-vmsr-helper and elf2dmp into the tools/ directory. > > > > > > > > The patchseries also moves the ebfp skeleton sources from tools/ebpf/ > > > > to ebpf/bpf-src/, because this isn't a tool by the above definition. > > > > > > > > As per my thread from a while back, I would ultimately like us to > > > > clean up contrib/: > > > > https://lore.kernel.org/qemu-devel/CAFEAcA_5HvGriDsWnb1ALuA_dgG320eKv7yuM2kThv=rfos...@mail.gmail.com/ > > > > But parts of that clearly need more discussion. So this is just doing > > > > some parts that I hope are not controversial. > > > > > > > > Annoyingly, meson doesn't seem to provide any way for a subdirectory > > > > meson.build to say "the foo.c in this subdir builds into a foo > > > > executable that lives at the top level of the builddir". And we have a > > > > lot of test harness stuff plus user muscle memory that assumes that > > > > qemu-img and qemu-io live there. So the build runes for these tools > > > > have to stay in the top level meson.build (and tools/meson.build > > > > remains an empty file). The exception is that contrib/elf2dmp/elf2dmp > > > > is now tools/elf2dmp/elf2dmp, but I think the set of people who were > > > > running that from the build directory will be small. > > > > > > > > > > It's a deliberate design more than an annoyance. It pushes users to make > > > things explicit at top level, which is good to understand what is built > > > and how, and hide details in subdirs in variables. QEMU's top level > > > meson.build is over complex, so it may appear more as a burden than a > > > benefit though. > > > > Personally I think if the build system doesn't let you do a > > pretty normal and reasonable thing that's annoying. Meson > > annoys me because it has a tendency to be over-opinionated.
Being opinionated is a double edge sword. A big part of the mess you get with traditional build tools is that they are not opinionated so every project ends up doing something slightly different and thus it is harder to understand each project. Being opinionated is what keeps meson simpler to understand and learn, at the cost of loss of flexiblity. Meson may not have the balance entirely right, but overall I think it has been beneficial to be very opinionated, even if that means some places needs to be relaxed over time. > I have to agree that meson is sometimes lacking. In this case, it > would be convenient to have a link created at build time. But you have > to resort to fairly annoying custom_target python code today. In the > meantime, there is also fs.copyfile() that could work (although it's > also somewhat limited or buggy). For later, we could try adding > fs.symlink() perhaps. Paolo might have better chances than me getting > it accepted ;) 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. 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. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
