Create Task
Maniphest T13778

Expand Project Filter capabilities to auto-detect build directories and exclude them by default
Open, NormalPublic
Actions

Description

KDevelop creates a build directory named "build" in the project root directory by default. This directory is shown in Projects tool view and files within are present in Quick Open file list, unless the user manually adds a matching Exclude Project Filter. This directory is normally not useful in the Projects tool view and in the Quick Open file list. Therefore it is desirable to filter it out by default.

For example, one more type of Targets can be added in addition to the existing "Files", "Folders", "Files and Folders": "Build Directory". There can be one default pattern of this new type: *build*. The exact meaning of "Build directory" can be defined by classes derived from IProjectFileManager. For example, CMakeManager could check if the directory contains a CMakeCache.txt file.

See also a few comments that discuss this feature at https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/176#note_120698.

igorkushnir created this task.Oct 18 2020, 12:44 PM
igorkushnir triaged this task as Normal priority.
mwolff claimed this task.Oct 19 2020, 10:49 AM
igorkushnir added a comment.Nov 4 2020, 8:54 AM

I just noticed that when the build directory is filtered out, auto-generated headers, like build/app/debug.h do not appear in the Quick Open list. Apparently these headers are not pulled in by CMake targets. I think that losing these particular headers is not a big deal. But could this filtering remove more useful files from the list and the project tree? I guess not - because the auto-generated files in the build directory are not supposed to be edited and should usually be uninteresting.

mwolff added a comment.Nov 4 2020, 3:22 PM

Generated files should usually be added to the corresponding cmake target - if you don't then yes they won't show up after filtering the build dir (or when using a totally different path for the build dir).

I don't think this is really of concern. It more sounds like a bug in the CMake file.

Unrelated to that: we used to have a quick open provider for files in include paths too. Would be great to get that back at some point... That would also take care of this, and also get us easier access to header files in system include directories, which is sometimes useful to read documentation etc.

igorkushnir added a comment.Nov 4 2020, 3:36 PM

ecm_qt_declare_logging_category adds only the debug.cpp file, but not the debug.h file. Is this a bug in ECM?

mwolff added a comment.Nov 4 2020, 7:45 PM

yes, I guess if you open a project that uses that in qtcreator, you also wouldn't be able to open the debug.h header then

igorkushnir added a comment.EditedDec 18 2022, 9:05 AM

From https://api.kde.org/ecm/module/ECMQtDeclareLoggingCategory.html:

The generated source file will be added to the variable with the name <sources_var_name>. If the given argument is a target though, instead both the generated header file and the generated source file will be added to the target as private sources (since 5.80). The target must not be an alias.

KDevelop already requires KF5 version >= 5.91.0. If we pass a target instead of a CMake variable as the first argument to ecm_qt_declare_logging_category(), the debug.h file will appear in the Quick Open list.

Created a separate issue for this task here: https://invent.kde.org/kdevelop/kdevelop/-/issues/18