Re: [PATCH 0/6] build contrib/plugins using meson

[Pierrick Bouvier <pierrick.bouvier@linaro.org>]

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,
>