Hi Joel,
On 1/19/23 15:08, Joel Sherrill wrote:
Subject:
Re: [PATCH 1/1] RSB: Mitigate too short error reports
From:
Joel Sherrill <j...@rtems.org>
Date:
1/19/23, 15:08
To:
Frank Kühndel <frank.kuehn...@embedded-brains.de>
CC:
Chris Johns <chr...@rtems.org>, devel@rtems.org
On Thu, Jan 19, 2023 at 6:47 AM Frank Kühndel <
frank.kuehn...@embedded-brains.de> wrote:
Hello Chris,
Hello Joel,
On 1/16/23 18:27, Joel Sherrill wrote:
Subject:
Re: [PATCH 1/1] RSB: Mitigate too short error reports
From:
Joel Sherrill<j...@rtems.org>
Date:
1/16/23, 18:27
To:
Frank Kühndel<frank.kuehn...@embedded-brains.de>
CC:
Chris Johns<chr...@rtems.org>,devel@rtems.org
On Mon, Jan 16, 2023 at 8:46 AM Frank Kühndel <
frank.kuehn...@embedded-brains.de> wrote:
Hi Chris,
On 1/16/23 01:02, Chris Johns wrote:
Subject:
Re: [PATCH 1/1] RSB: Mitigate too short error reports
From:
Chris Johns<chr...@rtems.org>
Date:
1/16/23, 01:02
To:
Frank Kühndel<frank.kuehn...@embedded-brains.de>,devel@rtems.org
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.kuehn...@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.
I usually search the logs for "rror:" and that's the first time something
is reported
whether by make or gcc or whatever. It may not be the root cause but it
gets
me to the first report.
Cutting any of these long reports down is always going to be possible to
cut out the real issue. It's ok because it it's more than just an odd
setup
issue on the host, someone will have to build locally to reproduce the
issue.
And then they will get the full output.
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?
I am not against the error report and I do not say it is a useless
feature. It is just that I found the message ' See error report: %s'
confusing in those cases where the report does not contain the error
at all because it is too short (the error report consists simply of the
last 400 lines of the build log).
To answer your question, I believe there is always a build log - no
matter whether the `--log` option is used or not. In this case, removing
the error report and pointing to the build log in case of error (for
example like ' See build log: %s') would certainly solve all my
concerns.
But on the build@ reports, it is nice to have something. Many times it
is possible to diagnose the issue. Just in the past fifteen minutes,
there
was one which having the log made it clear that CentOS 7 and other older
distributions need to use a newer GCC. Having the info in the build@
message was more than enough to diagnose that.
On the other hand, implementing the error report took time and was
certainly done with good reason. I do not feel like I should be the one
deciding to remove it. Changing the message or simply closing
https://devel.rtems.org/ticket/4642 would also be perfectly valid for
me.
Changing the message to encourage --log or whatever guidance for
debug. I don't even mind it pointing to a URL with guidance on debugging
RSB build issues.
When I understand Joel right, he would keep the error report and prefers
to change the message.
In a perfect world, there would also be improvements on what's reported
but we know there is no perfect solution.
This brings the discussion back to decide on an
appropriate text. To make progress, I suggests
' See error report: %s\n'
' Note: In some cases the error appears only in\n'
' the complete build log (see --log option)'
If your are OK with this text, I am happy to prepare a patch. I also
welcome any other suggestion. If we cannot find any solution, I prefer
to close my ticket #4642 without any action taken.
I'm happy with text like that. Is there a ticket to improve the message
or should #4642 have a comment and the message improved?
I am aiming at closing my ticket. I can add a comment to #4642,
referring to this mailing list discussion and summarizing its result.
Then a will post a patch which should close that ticket, provided the
patch gets accepted.
Greetings
Frank
--joel
Greetings
fk
--joel
Greetings ... and a happy new year to you
Frank
--
embedded brains GmbH
Herr Frank KÜHNDEL
Dornierstr. 4
82178 Puchheim
Germany
email:frank.kuehn...@embedded-brains.de
phone: +49-89-18 94 741 - 23
mobile: +49-176-15 22 06 - 11
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
--
embedded brains GmbH
Herr Frank KÜHNDEL
Dornierstr. 4
82178 Puchheim
Germany
email: frank.kuehn...@embedded-brains.de
phone: +49-89-18 94 741 - 23
mobile: +49-176-15 22 06 - 11
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
