Version: 3.9.2 (using Devel) Compiler: GCC-4.4.0 -march=native -O2 -pipe OS: Linux Installed from: Compiled sources With the latest svn version of KDevelop4. In a cmake project, when you expand a node (executable name) you will see the .cpp file in there. But also in the same of that node you'll see it the .cpp files. Apol tells me it was a recently added feature. But I have to disagree on the feature. I find it plain tacky and confusing to see it that and inside that node also. I know they point to the same file and what not. But shouldn't they only appear in the executable node and not the main folder so it doesn't cause confusion and also to know which file it really belongs to?
Never understood that change either. What do you think guys?
It's also confusing when the project structure does not match the directory structure.
We already discussed this on the list before I changed this to what we have now. Back then nobody had good arguments against having the .cpp file visible in both subtree's. Reasons for doing that: - beginners don't find their source files (we had quite a couple of people on IRC having exactly that problem - header files are only under the folder, so you can't easily match them visually - filesystem browsing in the project tree is awkward, because the .cpp files are not directly in the folder where they are in the filesystem - on the other hand, its good to easily see which cpp files belong to a given target.
Oh and yes it is a little bit confusing right now because there's a bug in the cmake manager when the .cpp files are not in the same folder, but a subfolder (that doesn't have a cmake file itself). Thats a bug and already reported in another bugreport.
Yeah I understand. I know which folder my files belong to. But when it gets bigger and what not it'd be much harder to actually remember some of them. And when working on a certain executable. I wanna only it's file and not files from other ones also.
so what you actually want is a filter to concentrate on a certain node in the tree. thats a valid wish and has been already reported as such. *** This bug has been marked as a duplicate of bug 124003 ***