| Message ID | 20240814233645.944327-1-pierrick.bouvier@linaro.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | build contrib/plugins using meson | expand |
On Thu, Aug 15, 2024 at 1:37 AM Pierrick Bouvier <pierrick.bouvier@linaro.org> wrote: > Contrib plugins have been built out of tree so far, thanks to a Makefile. > However, it is quite inconvenient for maintenance, as we may break them, > especially for specific architectures. > > First patches are fixing warnings for existing plugins, then we add meson > support, and finally, we remove Makefile for contrib/plugins. > > Based on the proposal of Anton Kochkov on associated gitlab issue. > Solves: https://gitlab.com/qemu-project/qemu/-/issues/1710 Is the bug actually still there? The Makefile explains why it was done this way: # This Makefile example is fairly independent from the main makefile # so users can take and adapt it for their build. We only really # include config-host.mak so we don't have to repeat probing for # programs that the main configure has already done for us. In other words we should also take into account that there is a documentation benefit to having a Makefile that works across Windows, Darwin and generic ELF Unices. Anyway Philippe, Akihiko and Alex are the best people to decide. One argument from moving contrib/plugins to meson is that the Windows case depends on libqemu_plugin_api.a which is built with meson(*); that said, libqemu_plugin_api.a should be installed - which would justify it being used from an "external" makefile. Paolo (*) by the way,
Paolo Bonzini <pbonzini@redhat.com> writes: > On Thu, Aug 15, 2024 at 1:37 AM Pierrick Bouvier > <pierrick.bouvier@linaro.org> wrote: >> Contrib plugins have been built out of tree so far, thanks to a Makefile. >> However, it is quite inconvenient for maintenance, as we may break them, >> especially for specific architectures. >> >> First patches are fixing warnings for existing plugins, then we add meson >> support, and finally, we remove Makefile for contrib/plugins. >> >> Based on the proposal of Anton Kochkov on associated gitlab issue. >> Solves: https://gitlab.com/qemu-project/qemu/-/issues/1710 > > Is the bug actually still there? > > The Makefile explains why it was done this way: > > # This Makefile example is fairly independent from the main makefile > # so users can take and adapt it for their build. We only really > # include config-host.mak so we don't have to repeat probing for > # programs that the main configure has already done for us. > > In other words we should also take into account that there is a > documentation benefit to having a Makefile that works across Windows, > Darwin and generic ELF Unices. Anyway Philippe, Akihiko and Alex are > the best people to decide. We could keep the Makefile as an example but the meson file looks fairly easy to read. However it keeps growing warts to adapt to the fact its not integrated with the wider project. > One argument from moving contrib/plugins to meson is that the Windows > case depends on libqemu_plugin_api.a which is built with meson(*); > that said, libqemu_plugin_api.a should be installed - which would > justify it being used from an "external" makefile. > > Paolo > > (*) by the way,
On 8/15/24 04:42, Alex Bennée wrote: > Paolo Bonzini <pbonzini@redhat.com> writes: > >> On Thu, Aug 15, 2024 at 1:37 AM Pierrick Bouvier >> <pierrick.bouvier@linaro.org> wrote: >>> Contrib plugins have been built out of tree so far, thanks to a Makefile. >>> However, it is quite inconvenient for maintenance, as we may break them, >>> especially for specific architectures. >>> >>> First patches are fixing warnings for existing plugins, then we add meson >>> support, and finally, we remove Makefile for contrib/plugins. >>> >>> Based on the proposal of Anton Kochkov on associated gitlab issue. >>> Solves: https://gitlab.com/qemu-project/qemu/-/issues/1710 >> >> Is the bug actually still there? >> >> The Makefile explains why it was done this way: >> >> # This Makefile example is fairly independent from the main makefile >> # so users can take and adapt it for their build. We only really >> # include config-host.mak so we don't have to repeat probing for >> # programs that the main configure has already done for us. >> >> In other words we should also take into account that there is a >> documentation benefit to having a Makefile that works across Windows, >> Darwin and generic ELF Unices. Anyway Philippe, Akihiko and Alex are >> the best people to decide. > > We could keep the Makefile as an example but the meson file looks fairly > easy to read. However it keeps growing warts to adapt to the fact its > not integrated with the wider project. > As you wish, but I think it's very confusing to have both. In more, you *need* meson to build the lib to which the plugin is linked, so it's not possible to compile a plugin with only a Makefile from scratch. >> One argument from moving contrib/plugins to meson is that the Windows >> case depends on libqemu_plugin_api.a which is built with meson(*); >> that said, libqemu_plugin_api.a should be installed - which would >> justify it being used from an "external" makefile. >> >> Paolo >> >> (*) by the way, >
On 8/14/24 23:00, Paolo Bonzini wrote: > On Thu, Aug 15, 2024 at 1:37 AM Pierrick Bouvier > <pierrick.bouvier@linaro.org> wrote: >> Contrib plugins have been built out of tree so far, thanks to a Makefile. >> However, it is quite inconvenient for maintenance, as we may break them, >> especially for specific architectures. >> >> First patches are fixing warnings for existing plugins, then we add meson >> support, and finally, we remove Makefile for contrib/plugins. >> >> Based on the proposal of Anton Kochkov on associated gitlab issue. >> Solves: https://gitlab.com/qemu-project/qemu/-/issues/1710 > > Is the bug actually still there? > Maybe the changes you did fixed the portability issue. I just added this "solves" because it's where the idea to compile with meson was presented initially. > The Makefile explains why it was done this way: > > # This Makefile example is fairly independent from the main makefile > # so users can take and adapt it for their build. We only really > # include config-host.mak so we don't have to repeat probing for > # programs that the main configure has already done for us. > > In other words we should also take into account that there is a > documentation benefit to having a Makefile that works across Windows, > Darwin and generic ELF Unices. Anyway Philippe, Akihiko and Alex are > the best people to decide. > > One argument from moving contrib/plugins to meson is that the Windows > case depends on libqemu_plugin_api.a which is built with meson(*); > that said, libqemu_plugin_api.a should be installed - which would > justify it being used from an "external" makefile. > You need meson to build this lib in the first place, so I guess that 99.9% of the people writing a plugin will have a qemu source tree (with access to plugin headers), and first compile the lib. I am not convinced by the scenario where people build this out of tree to be honest, but I may be wrong. > Paolo > > (*) by the way, >
On Thu, Aug 15, 2024 at 8:04 PM Pierrick Bouvier <pierrick.bouvier@linaro.org> wrote: > > One argument from moving contrib/plugins to meson is that the Windows > > case depends on libqemu_plugin_api.a which is built with meson(*); > > that said, libqemu_plugin_api.a should be installed - which would > > justify it being used from an "external" makefile. > > You need meson to build this lib in the first place, so I guess that > 99.9% of the people writing a plugin will have a qemu source tree (with > access to plugin headers), and first compile the lib. Note that the lib is built at configure time, not Make time. It's not a normal library. > I am not convinced by the scenario where people build this out of tree > to be honest, but I may be wrong. The idea is that people copy the Makefile, and yeah I'm not sure either if they do it but it can be useful. Paolo
On Thu, 15 Aug 2024 at 19:38, Paolo Bonzini <pbonzini@redhat.com> wrote: > > On Thu, Aug 15, 2024 at 8:04 PM Pierrick Bouvier > <pierrick.bouvier@linaro.org> wrote: > > > One argument from moving contrib/plugins to meson is that the Windows > > > case depends on libqemu_plugin_api.a which is built with meson(*); > > > that said, libqemu_plugin_api.a should be installed - which would > > > justify it being used from an "external" makefile. > > > > You need meson to build this lib in the first place, so I guess that > > 99.9% of the people writing a plugin will have a qemu source tree (with > > access to plugin headers), and first compile the lib. > > Note that the lib is built at configure time, not Make time. It's not > a normal library. > > > I am not convinced by the scenario where people build this out of tree > > to be honest, but I may be wrong. > > The idea is that people copy the Makefile, and yeah I'm not sure > either if they do it but it can be useful. The original theory was that since plugins are supposed to be independent of QEMU version that we should have the build system also be independent of QEMU (and perhaps that plugins might not be in the QEMU source tree at all some day). That's why they're in contrib/ (though I am not a fan of contrib/ as an organizational category in the filesystem...) -- PMM
On 15/8/24 20:04, Pierrick Bouvier wrote: > On 8/14/24 23:00, Paolo Bonzini wrote: >> On Thu, Aug 15, 2024 at 1:37 AM Pierrick Bouvier >> <pierrick.bouvier@linaro.org> wrote: >>> Contrib plugins have been built out of tree so far, thanks to a >>> Makefile. >>> However, it is quite inconvenient for maintenance, as we may break them, >>> especially for specific architectures. >>> >>> First patches are fixing warnings for existing plugins, then we add >>> meson >>> support, and finally, we remove Makefile for contrib/plugins. >>> >>> Based on the proposal of Anton Kochkov on associated gitlab issue. >>> Solves: https://gitlab.com/qemu-project/qemu/-/issues/1710 >> >> Is the bug actually still there? >> > > Maybe the changes you did fixed the portability issue. I just added this > "solves" because it's where the idea to compile with meson was presented > initially. > >> The Makefile explains why it was done this way: >> >> # This Makefile example is fairly independent from the main makefile >> # so users can take and adapt it for their build. We only really >> # include config-host.mak so we don't have to repeat probing for >> # programs that the main configure has already done for us. >> >> In other words we should also take into account that there is a >> documentation benefit to having a Makefile that works across Windows, >> Darwin and generic ELF Unices. Anyway Philippe, Akihiko and Alex are >> the best people to decide. >> > One argument from moving contrib/plugins to meson is that the Windows >> case depends on libqemu_plugin_api.a which is built with meson(*); >> that said, libqemu_plugin_api.a should be installed - which would >> justify it being used from an "external" makefile. >> > > You need meson to build this lib in the first place, so I guess that > 99.9% of the people writing a plugin will have a qemu source tree (with > access to plugin headers), and first compile the lib. > > I am not convinced by the scenario where people build this out of tree > to be honest, but I may be wrong. Consider users interested to use plugins (not really develop them). They should be able to build the plugins with their distrib QEMU, not cloning the whole git tree. (At least this is how I understood when Alex explained me the plugins power and simplicity for users.)
I don't have strong opinion in the end, I'm just looking for building contrib plugins like the rest of the codebase, to reduce maintenance burden. Initially, when this idea was implemented, it was suggested by Alex to remove the Makefile [1]. Now it seems to be suggested to keep it as an example. So I'll let you decide what's the best, I'll follow that. [1] https://lore.kernel.org/qemu-devel/20230615141315.961315-1-anton.kochkov@proton.me/T/#m2237fb20b9a53bd2ddec221831692090cda14c6f On 8/15/24 23:50, Philippe Mathieu-Daudé wrote: > On 15/8/24 20:04, Pierrick Bouvier wrote: >> On 8/14/24 23:00, Paolo Bonzini wrote: >>> On Thu, Aug 15, 2024 at 1:37 AM Pierrick Bouvier >>> <pierrick.bouvier@linaro.org> wrote: >>>> Contrib plugins have been built out of tree so far, thanks to a >>>> Makefile. >>>> However, it is quite inconvenient for maintenance, as we may break them, >>>> especially for specific architectures. >>>> >>>> First patches are fixing warnings for existing plugins, then we add >>>> meson >>>> support, and finally, we remove Makefile for contrib/plugins. >>>> >>>> Based on the proposal of Anton Kochkov on associated gitlab issue. >>>> Solves: https://gitlab.com/qemu-project/qemu/-/issues/1710 >>> >>> Is the bug actually still there? >>> >> >> Maybe the changes you did fixed the portability issue. I just added this >> "solves" because it's where the idea to compile with meson was presented >> initially. >> >>> The Makefile explains why it was done this way: >>> >>> # This Makefile example is fairly independent from the main makefile >>> # so users can take and adapt it for their build. We only really >>> # include config-host.mak so we don't have to repeat probing for >>> # programs that the main configure has already done for us. >>> >>> In other words we should also take into account that there is a >>> documentation benefit to having a Makefile that works across Windows, >>> Darwin and generic ELF Unices. Anyway Philippe, Akihiko and Alex are >>> the best people to decide. >>> > One argument from moving contrib/plugins to meson is that the Windows >>> case depends on libqemu_plugin_api.a which is built with meson(*); >>> that said, libqemu_plugin_api.a should be installed - which would >>> justify it being used from an "external" makefile. >>> >> >> You need meson to build this lib in the first place, so I guess that >> 99.9% of the people writing a plugin will have a qemu source tree (with >> access to plugin headers), and first compile the lib. >> >> I am not convinced by the scenario where people build this out of tree >> to be honest, but I may be wrong. > > Consider users interested to use plugins (not really develop them). > They should be able to build the plugins with their distrib QEMU, > not cloning the whole git tree. (At least this is how I understood > when Alex explained me the plugins power and simplicity for users.)