Re: [RFC PATCH v2] meson: Only generate trace files for selected targets

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

On 3/9/21 9:41 AM, Claudio Fontana wrote:
> On 3/8/21 6:48 PM, Philippe Mathieu-Daudé wrote:
>> On 3/8/21 5:46 PM, Stefan Hajnoczi wrote:
>>> On Wed, Feb 24, 2021 at 10:35:15PM +0100, Philippe Mathieu-Daudé wrote:
>>>> We don't need to generate trace files for targets we
>>>> are not building. Restrict the the ones selected.
>>>>
>>>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>>>> ---
>>>>  meson.build | 16 ++++++++--------
>>>>  1 file changed, 8 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/meson.build b/meson.build
>>>> index 05a67c20d93..8503aa1b628 100644
>>>> --- a/meson.build
>>>> +++ b/meson.build
>>>> @@ -1826,16 +1826,16 @@
>>>>    trace_events_subdirs += [
>>>>      'accel/tcg',
>>>>      'hw/core',
>>>> -    'target/arm',
>>>> -    'target/hppa',
>>>> -    'target/i386',
>>>>      'target/i386/kvm',
>>>
>>> Please add a comment explaining why an exception is needed here and the
>>> rest of the target directories are handled by the loop below when you
>>> send a non-RFC patch.
>>
>> Better would be a recursive function that adds the directory if
>> necessary. But I'm happy adding a simple comment =)
>>
>>>
>>> That will help people who add sub-directories in the future.
>>
>> Yes. Anyhow I expect this to clash with Claudio's work in progress
>> (which split target/ and add multiple subdirectories).
>>
>>
> 
> np, just the tracedirs should be easy to solve;
> 
> I personally don't see updating a simple list as difficult for the dev; does generating trace files for all require a lot of time?
> 
> In any case, I agree that just recursing all directories in target/ looking for trace.h / traceevents files could be better.
> 
> But how much time do we spare, compared with just generating all?

Well now on slow 32-bit hosts my impression is we spend more time in
meson / generating trace boilerplate files (even if the python code
is trivial, it is invoked many times) rather than compiling C.

trace doesn't use Kconfig to filter, so everything is processed.
Maybe the root problem is 'hw/core' actually, not the 'target/'
directories...

This is more noticeable for the user-only builds, which are the
ones likely to be supported longer on 32-bit hosts (there are
some discussions about keeping maintaining sysemu there).

That said this is user experience feeling and I didn't care to
benchmark it.

Anyhow this doesn't seem to have big impact (yet) so let's
postpone this series.

Thanks,

Phil.