Version: 3.9.98 (using KDevPlatform 0.9.98) (using 4.3.5 (KDE 4.3.5) "release 3", KDE:KDE4:STABLE:Desktop / openSUSE_11.2) Compiler: gcc OS: Linux (x86_64) release 2.6.31.12-0.1-default My project has a .kdev_include_paths file in the top-level build folder. The .kdev_include_paths file contains full paths to several 3rd party libraries used in the project like Xerces, RogueWave, Boost, etc. In fact, it is an exact copy of all include paths passed to the C++ compiler during compilation via -I. Whenever I open a header or source file that includes any of the headers from these 3rd party libraries, Kdevelop highlights the include directive for the 3rd party lib header in red, and the problems tab is full of messages like: Build manager did not return an include path Preprocessor headerfile.h 1 1 Included file was not found: xerces/util/PlatformUtils.hpp Preprocessor headerfile.h 1 1 Include file resolver: Makefile is missing in folder "<path to folder containing 3rd party library header>" Preprocessor headerfile.h If I manually open such a 3rd party library header, then kdevelop fails to find any headers included from that header, etc. Also, Kdevelop's parser seems to have a really tough time understanding macros in 3rd party lib files like the following 0 it highlights in red both braces around the macro parameter. RW_POINTER_DECLARE_TRACEABLE_TEMPLATE_CLASS(RWTCountingBody) IMHO, when a 3rd party library header is opened/parsed the same .kdev_include_paths file should be used as for parsing project files. Also, why is a makefile expected to be present in the directory with header files?
There's no makefile expected, we just try to run make there to get some informations about possible includes. Especially with custom make projects. The include-path-resolver is just a fallback-mechanism meant for cases where errors in the buildsystem plugin prevent proper include-path provisioning. Its not meant to be a solution to the problem of not using a supported buildsystem. Maybe you should have a look at the custom buildsystem plugin at http://gitorious.org/kdevelop4-custom-buildsystem
In fact, I recall David saying that we should disable the include-path-resolver as the cmake plugin (our main buildsystem target currently) does provide correct includepaths nowadays.
(In reply to comment #2) > In fact, I recall David saying that we should disable the include-path-resolver > as the cmake plugin (our main buildsystem target currently) does provide > correct includepaths nowadays. I don't see how that would help non-cmake users.
FYI - you may want to share this with the rest of developers (you can ask Alexander Dymo to translate ...): http://www.linux.org.ru/polls/polls/4598713
(In reply to comment #3) > (In reply to comment #2) > > In fact, I recall David saying that we should disable the include-path-resolver > > as the cmake plugin (our main buildsystem target currently) does provide > > correct includepaths nowadays. > > I don't see how that would help non-cmake users. It won't. The point is cmake is our main target right now, the only other thing we support on a very basic level is custom makefiles. However that plugin simply doesn't support specifying includedirs etc. The include-path resolver was always just meant as a workaround when there were still bugs in the cmake plugin and it provided wrong/not all include's.
I'm planning to at least make the include-path resolver optional, but the cmake support still doesn't seem to work in 100% of the cases, and it stays very useful for custom-makefile projects.
(In reply to comment #6) > I'm planning to at least make the include-path resolver optional, but the cmake > support still doesn't seem to work in 100% of the cases Do we have bugreports for that? > and it stays very useful for custom-makefile projects. For 4.0 thats ok, for 4.1 I'm planning to move the include-path-editing-widget from the custom-buildsystem plugin (http://gitorious.org/kdevelop4-custom-buildsystem) into kdevplatform and re-use it for custom makefile projects. Another option for people using custom-makefile projects is to simply use the custom-buildsystem plugin.
*** Bug 227164 has been marked as a duplicate of this bug. ***
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone!
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!