KDE/kdevelop/languages/cpp

[Matt Rogers]

On Jun 26, 2007, at 10:00 PM, Alexander Neundorf wrote:

> On Tuesday 26 June 2007 21:21, Matt Rogers wrote:
>> On Tuesday 26 June 2007 04:20, David Nolden wrote:
> ...
>>> 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.
>
> This is invalid. If somebody needs some information from cmake,  
> this can be
> added to the generators in cmake, where you can export the data you  
> want in
> the format you want and you can have it tested every night, then  
> breakages
> will be fixed by the developers within in few days.
>

We're not using the generators in CMake, so this is still worthless.

>> 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.
>
> I didn't follow closely.
> How is this currently implemented/planned ?
>
> E.g. if you have
> find_path(SOME_DIR foo.h PATHS /opt/foo )
> include_directories(${SOME_DIR})
>
> Another option is e.g.
> execute_process(foo-config OUTPUT result)
> ... some regexp stuff...
> include_directories(${RESULT_OF_REGEXPS})
>
> CMake is no standardized language, so it can be extendend and new  
> stuff can be
> added.
>
> How is all this handled ?
>
> Alex
>

The same that CMake does it, via parsing and intrepretation.
--
Matt