Bug #11207 2007-05-29 09:43

jazzer

doesn't jump to an error

I'm trying to build from C::B and just to errors from compiler output.

C::B parses the compiler's output correctly - populates the build messages grid with filenames, line numbers etc. This looks fine.

But when I double-click an error, it doesn't go the the file.

In my case the file is in $(project_base)/dir1/dir2/dir3/file.cpp, and in the build messages grid it's displayed as just file.cpp, with no path information. The file with name "file.cpp" is the only in the project, so there is no problem for C::B to find it just from the file name, even if the path info is missing.

Looks like cbProject::GetFileByFilename needs to be changed.

Category
Compiler
Group
 
Status
Closed
Close date
2013-02-13 05:23
Assigned to
biplab
biplab 2007-05-29 16:48

Please provide the svn revision number (preferably the complete

build information) with *every* bug report.

The complete build information is automatically copied to the

clipboard if you click the "Report a bug" link or the revision

string on the "Start Here" page.

Without accurate information, we are unable to reproduce and

address bugs.

jazzer 2007-05-30 02:09

it's "svn build rev 3988 (2007-05-22 16:45:47) gcc 3.4.5 Windows/unicode" (I took the installer from the site)

biplab 2007-05-30 11:54

I think you are using *project_base* variable which is not being expanded by C::B. Please check whether the variable is defined or not.

You may also a sample project file with the complete source.

jazzer 2007-05-30 12:16

*project_base* is not a variable, it's just a directory. Sorry for the confusion.

Say the project directory is /tmp, and the file is /tmp/dir1/dir2/file.cpp.

When the compiler reports errors in the form "dir1/dir2/file.cpp:11:" - everything is fine and C::B can find the source, but if it's just "file.cpp:11:" (with no path information) - it fails.

The same problem with debugger (see the bug 11208), I believe they both use the same function to find the file within the project.

biplab 2007-06-11 08:46

Does this bug persists?? I'm unable to reproduce it.

If it persists in your system, please upload a sample project where it fails stating the revision number that you're using.

pauliusz 2007-06-13 21:25

Maybe it is the same bug as Bug #11243?

jazzer 2007-06-14 03:44

> Maybe it is the same bug as Bug #11243?

No, it's different.

The problem is that there is no way to open a file just by name, if the file is not in the project root directory, but in some directory inside.

So my request actually is simple.

Current C::B behaviour:

if (path is absolute) open as is

else open relative to the project root (i.e.)

I'd like to extend this with an additional branch:

if there is no such file in the project root, try to find the file in the project tree.

For example, if the file is /tmp/dir1/dir2/file.cpp and project root is /tmp, so:

"/tmp/dir1/dir2/file.cpp" - absolute path, open as is;

"dir1/dir2/file.cpp" - relative path, prepend project root (it will give "/tmp/dir1/dir2/file.cpp") and open;

"dir2/file.cpp" - relative path, prepend project root (it will give "/tmp/dir2/file.cpp") and try to open - failed, try to find this in the project tree (should be very fast, as the project tree is in memory), find in dir1 and open;

"file.cpp" - just a file name, prepend project root (it will give "file.cpp") and try to open - failed, try to find this in the project tree (again, should be very fast), find in dir1/dir2 and open.

Of course, there is a problem with duplicates, but when you have just a file name - you have no better choice. Of course, various smart techniques can be used to distinguish between different files with the same name, but it's not for the near future. For now it's enough just show the list of possibilities and let user to decide.

What do you think? Is it possible? This would be a great help to all people who use complicated build procedures and strange development tools and tries to tie them with C::B.

biplab 2013-02-13 05:23

Please try with a nightly build and reopen this bug report, if

needed.

See http://forums.codeblocks.org/index.php/board,20.0.html