<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 16, 2023 at 8:46 AM Frank Kühndel <<a href="mailto:frank.kuehndel@embedded-brains.de">frank.kuehndel@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Chris,<br>
<br>
On 1/16/23 01:02, Chris Johns wrote:<br>
> Subject:<br>
> Re: [PATCH 1/1] RSB: Mitigate too short error reports<br>
> From:<br>
> Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>><br>
> Date:<br>
> 1/16/23, 01:02<br>
> <br>
> To:<br>
> Frank Kühndel <<a href="mailto:frank.kuehndel@embedded-brains.de" target="_blank">frank.kuehndel@embedded-brains.de</a>>, <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> <br>
> <br>
> On 22/12/2022 9:09 pm, Frank Kühndel wrote:<br>
>> On 12/21/22 00:06, Chris Johns wrote:<br>
>>> On 21/12/2022 3:44 am, Frank Kuehndel wrote:<br>
>>>> From: Frank Kühndel<<a href="mailto:frank.kuehndel@embedded-brains.de" target="_blank">frank.kuehndel@embedded-brains.de</a>><br>
>>>><br>
>>>> Close #4642<br>
>>>> ---<br>
>>>> source-builder/sb/ereport.py | 4 ++++<br>
>>>> 1 file changed, 4 insertions(+)<br>
>>>><br>
>>>> diff --git a/source-builder/sb/ereport.py b/source-builder/sb/ereport.py<br>
>>>> index d8fb5f6..d391917 100755<br>
>>>> --- a/source-builder/sb/ereport.py<br>
>>>> +++ b/source-builder/sb/ereport.py<br>
>>>> @@ -55,6 +55,10 @@ def generate(name, opts, header = None, footer = None):<br>
>>>> with open(name, 'w') as l:<br>
>>>> l.write(os.linesep.join(r))<br>
>>>> log.notice(' See error report: %s' % (name))<br>
>>>> + log.notice(' (Hint: The first error may be in front of a '<br>
>>>> + 'line containing\n'<br>
>>>> + ' "Error 1" [GNU make] and may be only in the whole log '<br>
>>> Is this too specific to GNU make? What ifs a package uses cmake or something<br>
>>> else?<br>
>> As the text indicates, this is specific to GNU make. For those using something<br>
>> else reading this text will still hint that the first error may not be in the<br>
>> end of the report "and may be only in the whole log".<br>
>><br>
>> Another weak point in this text is that by far not all errors originating from<br>
>> "make". Yet, the true trouble is the original "See error report: %s" where it<br>
>> can sometimes happen that the error is not in this "error report" at all.<br>
>><br>
>> I found it difficult to find a wording which is short, clear and helpful to the<br>
>> reader and at the same time not confusing. I am not perfectly happy with the<br>
>> notice above. I just found it a reasonable compromise.<br>
>><br>
>> If you prefer more generic texts - such as the examples below - I will send a<br>
>> new patch with the suggested test.<br>
>><br>
>> "Hint: The first error may be far way from the end of the<br>
>> report and in cases can only be found in the whole build log."<br>
>><br>
>> "Hint: The error is most likely in the error report otherwise<br>
>> see the whole build log [--log option]."<br>
>><br>
>> If you find any such change might cause more confusion than it might be helpful,<br>
>> I think it better to close this bug than to try to fix it.<br>
>><br>
> I think all you have written is valid and I have found the wording difficult.<br>
> There will never be a robust error message scanner or a simple full proof way to<br>
> find errors. The parallel builds makes tracking the errors difficult and the<br>
> point of error and end of the build a long distance apart.<br></blockquote><div><br></div><div>I usually search the logs for "rror:" and that's the first time something is reported</div><div>whether by make or gcc or whatever. It may not be the root cause but it gets</div><div>me to the first report. </div><div><br></div><div>Cutting any of these long reports down is always going to be possible to</div><div>cut out the real issue. It's ok because it it's more than just an odd setup</div><div>issue on the host, someone will have to build locally to reproduce the issue.</div><div>And then they will get the full output.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> As a result I question the value of the report and wonder if it should be<br>
> removed. The report adds overhead to the build as the logging process needs to<br>
> maintain a buffer of lines that is always updating. Your attention and interest<br>
> around this feature highlights how problematic it is so maybe it is simpler and<br>
> better to remove it and we leave users to find the error in the log file.<br>
> <br>
> I am happy to accept the report has not worked as a feature, remove it and in<br>
> the process we recover some overheads in the logging area of the RSB?<br>
> <br>
<br>
I am not against the error report and I do not say it is a useless <br>
feature. It is just that I found the message ' See error report: %s' <br>
confusing in those cases where the report does not contain the error<br>
at all because it is too short (the error report consists simply of the <br>
last 400 lines of the build log).<br>
<br>
To answer your question, I believe there is always a build log - no <br>
matter whether the `--log` option is used or not. In this case, removing <br>
the error report and pointing to the build log in case of error (for <br>
example like ' See build log: %s') would certainly solve all my concerns.<br></blockquote><div><br></div><div>But on the build@ reports, it is nice to have something. Many times it </div><div>is possible to diagnose the issue. Just in the past fifteen minutes, there</div><div>was one which having the log made it clear that CentOS 7 and other older</div><div>distributions need to use a newer GCC. Having the info in the build@</div><div>message was more than enough to diagnose that. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
On the other hand, implementing the error report took time and was <br>
certainly done with good reason. I do not feel like I should be the one <br>
deciding to remove it. Changing the message or simply closing <br>
<a href="https://devel.rtems.org/ticket/4642" rel="noreferrer" target="_blank">https://devel.rtems.org/ticket/4642</a> would also be perfectly valid for me.<br></blockquote><div><br></div><div>Changing the message to encourage --log or whatever guidance for</div><div>debug. I don't even mind it pointing to a URL with guidance on debugging </div><div>RSB build issues.</div><div><br></div><div>--joel </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Greetings ... and a happy new year to you<br>
Frank<br>
<br>
-- <br>
embedded brains GmbH<br>
Herr Frank KÜHNDEL<br>
Dornierstr. 4<br>
82178 Puchheim<br>
Germany<br>
email: <a href="mailto:frank.kuehndel@embedded-brains.de" target="_blank">frank.kuehndel@embedded-brains.de</a><br>
phone: +49-89-18 94 741 - 23<br>
mobile: +49-176-15 22 06 - 11<br>
fax: +49-89-18 94 741 - 08<br>
<br>
Registergericht: Amtsgericht München<br>
Registernummer: HRB 157899<br>
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
Unsere Datenschutzerklärung finden Sie hier:<br>
<a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div>