clicking a relative path in the build output opens the wrong file
Builder offers the possibility to open a file from clicking a warning/error message in the build output. However, when the path clicked is relative and there is a file with the same name in the project's source directory this file is opened, even if there is a better match for the full path in the build directory.
Here is an example project reproducing the issue:
reproduce-wrong-file-opened/ ├── meson.build └── subprojects └── my_dep └── meson.build
# meson.build project('my-top-level-project') my_dep = dependency('my_dep')
# subprojects/my_dep/meson.build "wrong syntax
meson /home/michaelmera/Projects/reproduce-wrong-file-opened . --prefix /home/michaelmera/.var/app/org.gnome.Builder/cache/gnome-builder/install/reproduce-wrong-file-opened/host The Meson build system Version: 0.62.2 Source dir: /home/michaelmera/Projects/reproduce-wrong-file-opened Build dir: /home/michaelmera/.var/app/org.gnome.Builder/cache/gnome-builder/projects/reproduce-wrong-file-opened/builds/default-host-x86_64-unversioned Build type: native build Project name: my-top-level-project Project version: undefined Host machine cpu family: x86_64 Host machine cpu: x86_64 Found pkg-config: /usr/bin/pkg-config (1.8.0) Found CMake: /usr/bin/cmake (3.22.2) Run-time dependency my_dep found: NO (tried pkgconfig and cmake) Looking for a fallback subproject for the dependency my_dep Executing subproject my_dep ../../../../../../../../../Projects/reproduce-wrong-file-opened/subprojects/my_dep/meson.build:1:0: ERROR: Double quotes are not supported. Use single quotes. "wrong syntax ^ A full log can be found at /home/michaelmera/.var/app/org.gnome.Builder/cache/gnome-builder/projects/reproduce-wrong-file-opened/builds/default-host-x86_64-unversioned/meson-logs/meson-log.txt
Clicking the link in the error message opens the
meson.build file at the top-level of the project instead of the one in the subproject
I tracked down the problem to the src/libide/gui/ide-workbench.c:ide_workbench_resolve_file_worker() function. The search roots are looked at in order and if no match is found it looks for a file with the same basename in the search root. This means that it will not even look at the build directory at all if there is a file with the same name in the project directory.
A simple fix would be to split this loop into two loops: first look at exact matches in each search root and second if no exact match has been found in any of these, it would look for a file with the same basename. I can submit a MR with this, but I'm not sure if changing it like that would break anything else.