Recently some people were complaining that whenever they were building certain of their projects and there was an error or a warning, that double clicking in the message pane wouldn't take them to the error.
Although for those people things have worked in the past.
The reason why it suddenly no longer worked was because the compiler is now handed over (at least for the MinGW) the full paths where in the past it was the relative path (relative to the cbp file). And those users had some special characters in their path (examples : # or [ or ]). The regular expressions used in the matching and the parsing of the output of the compilers did not allow such characters, and because of that, they couldn't provide a match, or only a partial match and as such provide the message pane with incomplete or incorrect information for the filename, line number, ....
For those users things have worked in the past because in the relative path those characters didn't show up.
Here's an example :
D:\Projects\My[1st]Project\Project.cbp
D:\Projects\My[1st]Project\main.cpp
In this case the main.cpp was handed over to the compiler as a relative path, being : "./main.cpp", and as such no sign of the special characters, and all was well.
Note however that the problem is present, when we consider the following project structure :
D:\Projects\My[1st]Project\Project.cbp
D:\Projects\My[1st]Project\src[sources]here\main.cpp
Now the main.cpp would be handed over to the compiler as : "./src[sources]here/main.cpp"
And the problem is visible.
So what has been done to fix this :
the previous regex for the filename part :
has been replaced by :
[][{}() \t#%$~A-Za-z0-9_:+/\\.-]+
And has been made available as a static const in the Compiler class, so that all build in compilers (which all derive from the Compiler class) can use it. Since in the past that regular expression was showing up several times, and not always correct (eg OpenWatcom didn't even allow spaces in the regex).
There are a few compilers where one regex is probably still not correct (MinGW is one of them), it about the second linker error :
m_RegExes.Add(RegExStruct(_("Linker error (2)"), cltError, _T("[][{}() \t#%$~A-Za-z0-9_:+/\\.-]+\\(.text\\+[0-9A-Za-z]+\\):([ \tA-Za-z0-9_:+/\\.-]+):[ \t](.*)"), 2, 1));
As you can see there are some groupings : where the first is used for the filename and the second for the message. But I wonder if that first grouping is correct for the filename, I would expect the part before that ".text" to be the filename. Is there anyone who knows the exact syntax of the error or even better who can give me an example of it.
So most probably it can be improve to be (haven't done that yet) :
m_RegExes.Add(RegExStruct(_("Linker error (2)"), cltError, _T("[][{}() \t#%$~A-Za-z0-9_:+/\\.-]+\\(.text\\+[0-9A-Za-z]+\\):([][{}() \t#%$~ \tA-Za-z0-9_:+/\\.-]+):[ \t](.*)"), 2, 1));
So how do you get these fixes to work. Well first let me explain how CB handles things.
The compiler settings are stored in your default.conf. Initially there's no default.conf, so CB creates it and fills in the compiler settings by using what the code instructs it to be. But once the entries are in the default.conf you can change whatever you want in the code, like providing new regular expressions, it will no end up in the default.conf and CB uses the information in the default.conf. So our nice fixes have no effect. That means we (the user) will have to help CB a little bit. We can either :
1) delete default.conf -> CB will recreate it with the new instructions from the code
[drawback : all our personal settings are gone]
2) inside the default.conf remove the compiler settings (or even the regex parts in this case are sufficient) parts : every compiler has its setting as a node of the <compiler><sets> nodes in the default.conf (which is xml) [so if you remove every compiler set there, CB will redetect, but your own changes to such a compiler set will be lost again]
3) manually change in the advanced options panel the regular expressions andmake sure you don't make mistakes ;-)
4) manually change the regular expressions in the default.conf and once again make sure you don't make any mistakes
5) ...
It is obvious 1) or 2) are the most easiest.
