GetFileByFilename upgrade suggestion (and filename processing)

[jazzer]

Hi, colleagues!

Please, could anyone add an option for cbProject::GetFileByFilename to return correct path to the file (with all subdirectories) when only filename is given.

This is needed to support tools/environments that give only filenames, with no path information.



Current C::B behaviour:
if (path is absolute) open as is else open relative to the project root (i.e. "$project_root/$relative_path")

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? (I think it should be quite simple as there is already a feature 'Find file' in the project tree.)

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.

references:
https://developer.berlios.de/bugs/?func=detailbug&group_id=5358&bug_id=11207
https://developer.berlios.de/bugs/?func=detailbug&group_id=5358&bug_id=11208
I saw a few more tracker items related to this problem, but can't find them now.

Additional/alternative option - to provide a hook for filename processing.
As I understand there are some hard-coded processing rules like 'GDB workaround' - so why not to do it generic and customizable? It should be a C::B macro function, that can contain anything, from the default implementation (do nothing) to regex processing, 'find file' call etc.
This will also help developers who use source code generators - when they receive an error regarding failed compilation of a generated file, they would like to automatically go to the generator/template/whatever file used for generation.

What do you think?
Thanks guys!

[MortenMacFly]

What do you think?

I don't think it's a good idea. It's simply black magic. If I got you right you are asking about to search for a file which isn't correctly proposed to C::B. As soon as you find one in *any* directory assume that's the one you are looking for. This is very bad! How do you figure out whether you don't have used the wrong file? Imagine you have a projects where filenames occure multiple times in a lot uf sub-directories (such projects exist!). You would pick the first one then because the user isn't clever enough to point to the correct file?! This will lead to even more errors than a wrong project setup IMHO. My opinion. Period.
With regards, Morten.

[jazzer]

Thanks for the reply, I totally agree with your concerns.
That's why I'm asking for _an option_ (maybe project/workspace option) which is off by default, not for a permanent change.

Also, if it works currently with your configuration, it will continue to work even if this option is turned on, because the new behavior will jump into game ONLY IF current algorithm failed to find the file.

Anyway, what is your opinion regarding filename processing?

[MortenMacFly]

Anyway, what is your opinion regarding filename processing?

There are plans to overwork the file processing anyway. Thus there is *one* instance (a true fileitemmanager or something) that has to be asked for file or file specific data such as path, relative path, parameters etc. This would ensure all "clients" will use a single interface which would reduce the such "hacking" a lot. Maybe this would already provide a method you are asking for in the future. Hence if not it would be easy to add. Don't ask when this will be ready - I don't know.
With regards, Morten.