April 26, 2003
GCC error handling
The reason I decided to play with the global output window (which isn't in CVS yet btw) was that earlier on I implemented simple GCC output handling (which is in CVS). When you click on any gcc message of the form:
PN2 will jump to "line" in "filename". The code currently is not that intelligent. It will only work in one of these two cases:
- The filename part is a fully-qualified path.
- The filename exists in the current directory.
I am unsure whether this is enough (and how to find the right file if it isn't), I need some sample output from GCC to test with - I guess I'll have to download and install it.
Once this is all working hunky-dory I'll try and add support for some other output types.
Working with this and clicking on an error, only to have it jump to another maximised window hiding the error message is what made it clear how important the global output window was going to be is what made me play with the docking code.
This week I've also added a "maximise on open/new" option to the options dialog so that you can work with maximised windows by default.
Posted by Simon at April 26, 2003 12:00 AM
In other editors, users can specify a 'rule' that is used to parse the output lines of a tool. For instance, to parse the following output
P:\dfs\CTD\prog\cir\main.ox (87): 'bla' undeclared identifier
I defined the rule
where %n is the file name and %l the line number. Further, you can use %c for column numbers and * for any text. Literal text is also allowed in the rule, like
Error * on line %n of file %l:
Although I don't know exactly how parser rules are implemented, but I do know it's a really flexible way to let users grab the output of any kind of tool.
Yes, I plan to implement something similar to what you describe. At the moment I am simply providing a few built-in rules to complement the parsing provided by Scintilla for certain output types. The user will be able to choose between the built-in rules and custom rules such as those you describe.
Here's a sample from WinAVR (GCC for AVR):
sprobe.c:111: warning: implicit declaration of function `__LPM_word_classic__'
So yes, it looks like in theory, this will work.
I'm glad you figured out that the global window was going to be the way to go for something like this. :)
I *think* your 2 cases for finding the file will be sufficient. However, what do you mean by "fully-qualified" path?
A user may have a multi-directory project. In this case, the filename part of the error might have a "relative" path (going off into a subdirectory of the current directory). So you might want to take the current directory and graft the path/filename from the error line and see if it exists then open.