KDE/kdevelop/languages/cpp

[Alexander Neundorf]

Hi,

-------- Original-Nachricht --------
Von: Andreas Pakulat <apaku at gmx.de>

> On 28.06.07 17:26:52, Alexander Neundorf wrote:
...
> > Ok, this sounds reasonable. But then why does it need to parse the
> > cmake files ? I'd really like to understand what the goal is.
> > Matt said he wants to get the include directories this way, which
> > sounds very different.
> 
> The include-dirs, the targets, possibly the libs, the files. No idea

That's exactly what the generators in cmake are for. With reimplementing this in kdevelop it will never work reliable, so kdevelop will never feel like a professional IDE.

> what else Matt has on his mind. And this does need a parser, else you'd
> have to re-run cmake on each and every change which takes quite some
> time on something like kdelibs. 

That's true. CMake runs in two phases: first configure, then generate. Quite some time for the configure step is IO (many small files) and some time is spent in parsing (according to valgrind). Maybe something like a  cache for all parsed cmake files could be done ?

> The parser is faster here, because it doesn't generate anything on disk.

... and because it doesn't do a lot and will not produce correct results.

The time for the generate step depends on the used generator. If generating the makefiles is the slow part, it's no major problem to separate this, so that you can tell cmake only to generate the xml (or whatever) files and skip the makefiles this time.
Currently cmake 2.6 is in development, so now is a good time for new features.

> As I said, Matt already tried once
> with a CMake generator that produced XML, but he said that didn't
> provide enough functionality.
> 
> > The first thing (simple setups) could be done with an "internal"
> > project
> 
> What do you mean with that? Its not just project creation, but also
> changing the project (adding/removing files, dirs...)

Think "kdevelop-own buildsystem" (as MSVC and XCode have). You create targets with source files, include dirs and libs via a GUI. Then kdevelop knows what you want to do, which files belong to the project, which include directories, etc.
When you are going to build and the build settings were changed in kdevelop, kdevelop generates the cmake files and reruns (a maybe internal copy of) cmake on these files. The user never sees or has to deal with the cmake files. If he finds and edits them, the changes will be ignored since the rules to rerun cmake automatically is disabled. So cmake is only run again if the settings were changed in kdevelop and kdevelop wrote the new cmake files.
If this happens with an internal copy of cmake (e.g. 2.4.5), this cmake will always be available if kdevelop is installed, cmake can be installed to any directory, e.g. to apps/kdevelop/buildtools/cmake-2.4.5/, and kdevelop can know exactly the names of the targets in the makefiles and where the generated files will go. It could even reuse some of the files generated by the (internal) cmake since this version is fixed so even files which are not guaranteed to stay in the same format can be used (e.g. the headers included by a source file, CMakeFiles/<target.dir>/CXX.includecache).

> > and wouldn't for the second just a wizard-like thingy which creates 
> > the cmake code and asks you where to put it be enough ?
> 
> No, because then the user really has a plain text file for the
> CMakeLists.txt. But IIRC Matt wants to provide some more help to the
> user (think target_link_libraries( <ctrl+space> -> list of libs in
> project). That stuff needs information from the buildsystem.

For this example with the libs it wouldn't be a problem (the project files have all the libs). It gets more interesting e.g. when completing find_package( . Then you need to know the current CMAKE_MODULE_PATH. Even this could be put in the project file. Same for include(.
configure_file( needs only the directory of this CMakeLists.txt. 
A real problem would be ${K <ctrl+space>, we can't store every variable in the project file. But then again, maybe simple autocompletion just with words which already appeared before would help already a lot.

So parsing separate cmake files in order to provide good autocompletion is ok, but doing it in order to get information (like include directories) out of them will just not work.

Alex

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger