Version: CVS (using KDE KDE 3.1.3) Installed from: SuSE RPMs Compiler: g++ (GCC) 3.3 20030226 (prerelease) (SuSE Linux OS: Linux I have an automake/autoconf project (with subprojects). The source and header files are separated in their own subdirectories. During generation of the project, these files where linked to the directory where the Makefile.am are. Everything was ok since a few days before alpha6. Since then the classbrowser is empty, and codecompletition is broken for my own classes. Only some base-classes created by "uic" are available. So I guess that the problem is, that the classbrowser is not able to parse linked files.
I've looked into this bug. In our projects it affects qmake projects, that have relative subdirs that don't sit below the project dir. (e.g. SUBDIRS=../libs/a ../libs/b project) The problem is the same in both cases: CppSupportPart::isValidSource uses canonical paths (i.e. absolute paths with resolved symlinks) to the source files but assumes that the source files have to be in a subdirectory below the current project dir. When looking for the files it takes the canonical path and removes the beginning of it up to the length of the current project dir path to get the relative path to the files. This only works if the file sits below the current project dir. Example for clarification: project |--- file.h -> ../libs/file.h libs |--- file.h original file path: /home/user/project/file.h == /home/user/project/../libs/file.h canonical path with resolved symlink: /home/user/libs/file.h project dir: /home/user/project assumed relative path to file (canonical path - project dir length): e.h which of course doesn't exist. This bug affects all files that don't sit below the current project dir (i.e. have relative paths with ../ or symlinks). (I changed the Summary to reflect this) Do we need this check in isValidSource (as javasupport also doesn't check this and it's difficult to get this right - I have a quick workaround here for our ../ subdir projects but to get the symlinks right is not as easy)! Roberto? The bug was also reported by somebody else on the kdevelop ML today so we should really get this fixed. It looks like a similar bug also prevents cvspart from working with these files.
I'm afraid that it isn't so simple the point is PartController::editDocument(..) (defined in kdevelop/src) resolves the link before open the editor! so, for instance the problem reporter will not be enabled if you call PartController::editDocument("<project-dir>/myfile.h") and myfile.h is a link to /usr/include/stdio.h. Maybe a possible solution could be to use a dictionary that maps absolute urls to project urls, something like QMap<QString,QString> absoluteFileToProjectFile; absoluteFileToProjectFile[ URLUtil::canonicalPath(fileName) ] = fileName; where fileName is a project relative file. This dictionary can be computed using KDevProject::allFiles() when the project emits signals addedFilesToProject(),removeFilesFromProject(),... in this way you can check if a file is a "project file" with absoluteFileToProjectFile.contains( absolute-url ) and the classbrowser can use the absoluteFileToProjectFile[ absolute-url ] for create the "folders". ciao robe
Subject: kdevelop CVS commit by raggi: improved the support for sourcefiles outside project directory CCMAIL: 64481-done@bugs.kde.org M +3 -1 buildtools/ada/adaproject_part.cpp 1.12 M +2 -0 buildtools/ant/antprojectpart.cpp 1.18 M +2 -0 buildtools/autotools/autoprojectpart.cpp 1.119 M +2 -0 buildtools/custommakefiles/customprojectpart.cpp 1.62 M +1 -0 buildtools/generic/genericproject_part.cpp 1.9 M +2 -0 buildtools/pascal/pascalproject_part.cpp 1.19 M +2 -0 buildtools/qmake/trollprojectpart.cpp 1.65 M +1 -0 buildtools/script/scriptprojectpart.cpp 1.36 M +0 -9 languages/cpp/cppsupport_utils.cpp 1.3 M +0 -1 languages/cpp/cppsupport_utils.h 1.3 M +1 -1 languages/cpp/cppsupportpart.cpp 1.234 M +33 -1 lib/interfaces/kdevproject.cpp 1.7 M +18 -2 lib/interfaces/kdevproject.h 1.25 M +11 -14 parts/classview/classviewwidget.cpp 1.44
*** Bug 65221 has been marked as a duplicate of this bug. ***
Moving all the bugs from the CPP Parser. It was not well defined the difference between it and C++ Language Support and people kept reporting in both places indistinctively