thanks… what i have done in other tools i create is provide my warn(), error() info() functions a context that included filename and line number, this simplifies ad standardizes reporting
you might for example create things like an errorHere() and similar function that takes a HERE context but i agree you are already quite a ways down that road and i agree it might be hard/disruptive to make that change. in a related thing: (makefiles) people often complain about excessive output during a build but at times it is useful. example: some invoke make in two steps: cd SOMEDIR ; make all it is actually better to use make -C SOMEDIR all reason: some tools (emacs, and vscode are two examples) these parse the output: make[x]: entering directory and make[x]: leaving directory why: because some times the error file is given as a relative path and other times it is an absolute path. and their error parser needs to find the actual file via a relative path from some random current directory other tools have added special parsing rules for perl and python error messages, but sadly i do not think these tools will be adding a custom error parser for bitbake any time soon. a cool trick btw is to load or just “cat LOGFILE” in the vscode terminal the terminal parses the out put and makes errors clickable same trick works in emacs.. and vim can do the same type of thing: https://stackoverflow.com/questions/42462408/automatically-go-to-next-compile-error-in-vim On Oct 2, 2024, at 00:04, Richard Purdie via lists.yoctoproject.org <richard.purdie=linuxfoundation....@lists.yoctoproject.org> wrote: On Wed, 2024-10-02 at 03:32 +0000, Duane Ellis via lists.yoctoproject.org wrote: It’s been reported before: https://lists.yoctoproject.org/g/yocto/topic/warning_image_fstypes_remove/103013050 The gripe I have is this: It occurs – but bitbake does *NOT* tell or give you a hint to *WHICH * bitbake file is causing this. Error and warning messages like this should include the recipe name or directory or something that This simple change would be very helpful to victims of this madness diff --git a/bitbake/lib/bb/parse/ast.py b/bitbake/lib/bb/parse/ast.py index 9e0a0f5c98..8e700b1043 100644 --- a/bitbake/lib/bb/parse/ast.py +++ b/bitbake/lib/bb/parse/ast.py @@ -132,7 +132,7 @@ class DataNode(AstNode): if ":append" in key or ":remove" in key or ":prepend" in key: if op in ["append", "prepend", "postdot", "predot", "ques"]: - bb.warn(key + " " + groupd[op] + " is not a recommended operator combination, please replace it.") + bb.warn(self.filename + ":%d: " % self.lineno + key + " " + groupd[op] + " is not a recommended operator combination, please replace it.") flag = None if 'flag' in groupd and groupd['flag'] is not None: I don't know why I didn't do that in the patch which added this code. Changing the warning to include the filename/lineno seems like a good idea and such a patch would probably get merged. BETTER – change the bb.warn() to *NOT* print WARNING: at the start of the line. But *AFTER* the ‘%d:’ Reason: BB does not use the well-known standard error reporting format used by just about every UNIX tool out there. Examples include: GCC, GREP (with the -n option) to name a few well- known examples. Why? Many tools, Eclipse (error parser), VSCODE, Emacs and VIM can parse the tool output in this form and turn the item into a clickable error in your IDE or EDITOR of your choice. But if the tool does not output this format it makes it harder to resolve errors This is a bit harder as bitbake can mix debug, normal output and warnings onto its console output. A prefix is used at the start of lines to make it much clearer in streams of logs where there are such messages. When running in larger builds, the messages can also be prefixed with the name of the recipe generating the message as in a multi-task environment, it has been found to be problematic not to know where the message was coming from. Given those reasons, I'm not sure we can easily change this. I do agree line/file info is sensible though. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#63931): https://lists.yoctoproject.org/g/yocto/message/63931 Mute This Topic: https://lists.yoctoproject.org/mt/108773605/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
