[PATCH 1/1] RSB: Mitigate too short error reports

[Chris Johns]

On 22/12/2022 9:09 pm, Frank Kühndel wrote:
> On 12/21/22 00:06, Chris Johns wrote:
>> On 21/12/2022 3:44 am, Frank Kuehndel wrote:
>>> From: Frank Kühndel<frank.kuehndel at embedded-brains.de>
>>>
>>> Close #4642
>>> ---
>>>   source-builder/sb/ereport.py | 4 ++++
>>>   1 file changed, 4 insertions(+)
>>>
>>> diff --git a/source-builder/sb/ereport.py b/source-builder/sb/ereport.py
>>> index d8fb5f6..d391917 100755
>>> --- a/source-builder/sb/ereport.py
>>> +++ b/source-builder/sb/ereport.py
>>> @@ -55,6 +55,10 @@ def generate(name, opts, header = None, footer = None):
>>>               with open(name, 'w') as l:
>>>                   l.write(os.linesep.join(r))
>>>               log.notice('  See error report: %s' % (name))
>>> +            log.notice('  (Hint: The first error may be in front of a '
>>> +                'line containing\n'
>>> +                '  "Error 1" [GNU make] and may be only in the whole log '
>> Is this too specific to GNU make? What ifs a package uses cmake or something
>> else?
> 
> As the text indicates, this is specific to GNU make. For those using something
> else reading this text will still hint that the first error may not be in the
> end of the report "and may be only in the whole log".
> 
> Another weak point in this text is that by far not all errors originating from
> "make". Yet, the true trouble is the original "See error report: %s" where it
> can sometimes happen that the error is not in this "error report" at all.
> 
> I found it difficult to find a wording which is short, clear and helpful to the
> reader and at the same time not confusing. I am not perfectly happy with the
> notice above. I just found it a reasonable compromise.
> 
> If you prefer more generic texts - such as the examples below - I will send a
> new patch with the suggested test.
> 
>     "Hint: The first error may be far way from the end of the
>     report and in cases can only be found in the whole build log."
> 
>     "Hint: The error is most likely in the error report otherwise
>     see the whole build log [--log option]."
> 
> If you find any such change might cause more confusion than it might be helpful,
> I think it better to close this bug than to try to fix it.
> 

I think all you have written is valid and I have found the wording difficult.
There will never be a robust error message scanner or a simple full proof way to
find errors. The parallel builds makes tracking the errors difficult and the
point of error and end of the build a long distance apart.

As a result I question the value of the report and wonder if it should be
removed. The report adds overhead to the build as the logging process needs to
maintain a buffer of lines that is always updating. Your attention and interest
around this feature highlights how problematic it is so maybe it is simpler and
better to remove it and we leave users to find the error in the log file.

I am happy to accept the report has not worked as a feature, remove it and in
the process we recover some overheads in the logging area of the RSB?

Chris