Under certain conditions, the Find/Replace in Files function fails to find any files matching the wildcard pattern. This happens for me when I use rather complex paths that are a result of building using a certain distribution system, but I think that shouldn't matter. I'll present an example for marble that should be reproducible. Reproducible: Always Steps to Reproduce: A 1. Create a work directory called, for instance, /opt/local/var/macports/build/_opt_local_site-ports_kf5_kf5-marble/kf5-marble/work 2. unpack the marble sources into /opt/local/var/macports/build/_opt_local_site-ports_kf5_kf5-marble/kf5-marble/work/marble-15.12.3 3. launch kdevelop5 4. open /opt/local/var/macports/build/_opt_local_site-ports_kf5_kf5-marble/kf5-marble/work/marble-15.12.3/CMakeLists.txt 5. accept the proposed build directory, /opt/local/var/macports/build/_opt_local_site-ports_kf5_kf5-marble/kf5-marble/work/marble-15.12.3/build 6. complete the project import 7. right-click on an entry in the project view, select Find/Replace in this folder and do a search on a string that is guaranteed to exist in the project. Actual Results: KDevelop will spend some time "collecting files", and then present the message that no files are found that match the wildcard pattern. Expected Results: search results showing all occurrences of the given search string - this has been the case since KDevelop 4.7 at least - Workaround: 1. Close the project in KDevelop 2. move the source directory (/opt/local/var/macports/build/_opt_local_site-ports_kf5_kf5-marble/kf5-marble/work/marble-15.12.3/) to a location with a shorter path, say $HOME/src/marble-15.12.3 3. ln -s $HOME/src/marble-15.12.3 /opt/local/var/macports/build/_opt_local_site-ports_kf5_kf5-marble/kf5-marble/work/marble-15.12.3 4. reopen the project (via Recent Projects) A priori the search function should work correctly now. - Most likely unrelated, but it seems the cmake importer wizard offers the 1st cmake exec found in the path rather than the version selected in the KDevelop settings.
I forgot to mention explicitly: this happens on both OS X and Linux; the above example was prepared and checked on Linux.
The issue is in the Exclude pattern. It contains "/build/" pattern by default to exclude the default-named directory KDevelop creates. And each Exclude pattern is matched against a complete file path. I think it should be matched against the remainder of the path after the top-level search directory. Note that right now the Exclude functionality is broken as described in Bug 417628. I'm working on a fix to that bug.
*** Bug 373456 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/519
Git commit 2ced983d4975cedb5166c4115397870aaab0e148 by Igor Kushnir. Committed on 15/01/2024 at 11:44. Pushed by igorkushnir into branch 'master'. GrepFindFilesThread: match relative paths against Exclude filter Two KDevelop users have reported the "No files found matching the wildcard patterns" bug when the project directory is within a parent directory named "build". The /build/ pattern is present in the default Exclude filter. Therefore, all absolute file paths in such a project directory match the default Exclude filter and are not searched in. Match paths relative to the current search location in order to fix the bug. A downside of this fix is that when multiple projects are open, excluding one of them from the search is no longer possible. Hopefully this is a very rare use case. FileFinder::findFilesCanonical: don't search in a subdirectory whose relative path matches the Exclude filter. Since the relative path to a file within a subdirectory contains the relative path to the subdirectory, it would also match the Exclude filter and therefore would not be inserted into the results list. FIXED-IN: 5.14 M +45 -8 plugins/grepview/grepfindthread.cpp M +1 -1 plugins/grepview/grepfindthread.h https://invent.kde.org/kdevelop/kdevelop/-/commit/2ced983d4975cedb5166c4115397870aaab0e148