KDE/kdevelop/languages/cpp

[David Nolden]

On Tuesday 26 June 2007 15:05:20 Kris Wong wrote:
> I wasn't trying to answer your question, just stating the reason the
> include path resolver was ported.  The issue of cmake generated
> Makefiles seems like a non-issue, though.  Why would the user not be
> using a cmake based project if they were using the cmake build system?

It's called "custom makefiles", so it should work with ANY makefiles, even 
cmake-generated ones. Also there's maybe other build-systems that act 
similar.

@Andres Pakulat
I have looked at the cmake-generated makefiles. They contain redirections to 
other directories, where make is called again. The include-path resolver 
follows that redirection, and the makefile-parser would need to do the same.

Example for such a redirection:
cppcodecompletionmodel.o:
        cd /media/data/kdedev/4.0/build/kdevelop && $(MAKE) -f 
languages/cpp/CMakeFiles/kdevcpplanguagesupport.dir/build.make 
languages/cpp/CMakeFiles/kdevcpplanguagesupport.dir/cppcodecompletionmodel.o

In the end it might be very similar to what the include-path-resolver does, 
except that the resolver leaves parsing the Makefile to make.

So it's less error-prone, because there is not an additional parser that can 
fail, which btw. does not exist at the moment. The good thing about a parser 
would be that it doesn't check dependencies etc so could be much faster.

We will see whether someone creates a Makefile-parser that delivers similar 
results. If someone does, we can drop the include-path-resolver, or change it 
so it incorporates the makefile-parser.

greetings, David