KDE/kdevelop/languages/cpp

[Andreas Pakulat]

On 26.06.07 11:20:18, 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?
> 
> Yes, with files that are not part of any project, and for debugging the 
> build-system include-path computing algorithms.

I don't see how the include-path-resolver can help here. IIRC it was
here, though not sure, that somebody posted a way to ask gcc for its
standard include dirs. That can be done when editing files outside any
project. After all thats all the paths you can find out about, without
having the user give you some more paths.

Unless of course the include-path-resolver does more than just finding
the include-paths for a given dir.

> 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.

Whats the problem with cmake-generated Makefile's? Yes, its not
dead-easy to parse these as you have to "follow" forwards and such, but
I don't think thats impossible to parse cmake-generated makefiles.

Andreas

-- 
You have been selected for a secret mission.