KDE/kdevelop/languages/cpp

[Matt Rogers]

On Tuesday 26 June 2007 04:20, David Nolden wrote:
> On Tuesday 26 June 2007 02:29:01 Matt Rogers wrote:
> > On Jun 24, 2007, at 3:19 PM, Kris Wong wrote:
> > > SVN commit 679743 by wongk:
> > >
> > > Ported IncludePathResolver from KDevelop 3.
> >
> > I'm not sure this will be/is needed anymore. The build systems should
> > provide the locations to search for includes. We've added mechanisms
> > to the build managers specially for this. Even the custom makefile
> > manager should know how to at least parse the Makefile to get this
> > information even if it doesn't allow editing it.
> >
> > Taking that information into account, are there other places where
> > this might be used?
> > --
> > Matt
>
> Yes, with files that are not part of any project, and for debugging the
> build-system include-path computing algorithms.
>

But this still misses include pathes for files that are not part of a project, 
does it not? Unless you go searching the whole file system, and I certainly 
hope that we're not doing that. Even then you could end up with conflicts 
(think Qt 3 vs. Qt 4)

> So it stays useful, especially for free editing.
>

I doubt it's usefulness.

> Also there currently is no build-system that returns include-paths. Another
> question is how to reliably parse make-files to get the include-paths, in
> many cases that might not be possible, for example with cmake-generated
> makefiles.
>

CMake used to do it before we started on this third round of cmake support and 
it will do it again soon. Anyways, you won't be parsing CMake generated 
Makefiles, you'll be parsing the CMakeLists.txt files themselves and get the 
include paths that way.
-- 
Matt