mbox series

[0/6] build contrib/plugins using meson

Message ID 20240814233645.944327-1-pierrick.bouvier@linaro.org (mailing list archive)
Headers show
Series build contrib/plugins using meson | expand

Message

Pierrick Bouvier Aug. 14, 2024, 11:36 p.m. UTC
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

Pierrick Bouvier (6):
  contrib/plugins/execlog: fix warning
  contrib/plugins/cache: fix warning when compiling on 32bits host
  contrib/plugins/hwprofile: fix warning when compiling on 32bits host
  contrib/plugins/hotblocks: fix warning when compiling on 32bits host
  meson: build contrib/plugins with meson
  contrib/plugins: remove Makefile for contrib/plugins

 configure                   | 18 --------
 Makefile                    | 10 -----
 meson.build                 |  4 ++
 contrib/plugins/cache.c     |  6 +--
 contrib/plugins/execlog.c   |  4 +-
 contrib/plugins/hotblocks.c |  4 +-
 contrib/plugins/hwprofile.c |  9 ++--
 contrib/plugins/Makefile    | 85 -------------------------------------
 contrib/plugins/meson.build | 23 ++++++++++
 9 files changed, 39 insertions(+), 124 deletions(-)
 delete mode 100644 contrib/plugins/Makefile
 create mode 100644 contrib/plugins/meson.build

Comments

Paolo Bonzini Aug. 15, 2024, 6 a.m. UTC | #1
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,
Alex Bennée Aug. 15, 2024, 11:42 a.m. UTC | #2
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,
Pierrick Bouvier Aug. 15, 2024, 5:42 p.m. UTC | #3
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,
>
Pierrick Bouvier Aug. 15, 2024, 6:04 p.m. UTC | #4
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,
>
Paolo Bonzini Aug. 15, 2024, 6:37 p.m. UTC | #5
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
Peter Maydell Aug. 15, 2024, 7:14 p.m. UTC | #6
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
Philippe Mathieu-Daudé Aug. 16, 2024, 6:50 a.m. UTC | #7
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.)
Pierrick Bouvier Aug. 16, 2024, 6:44 p.m. UTC | #8
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.)