KDE/kdevelop/languages/cpp

[Andreas Pakulat]

On 28.06.07 20:23:09, Alexander Neundorf wrote:
> > 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.

Would you please stop acusing us of being incapable of providing a
professional tool. Thanks.

Also what we really need is not just a plain list, we need to know which
target belongs to which subdir and which file belongs to which target.
Which subdir has which include dirs set and which libraries are linked
to which target.


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

Oh, you can look into the future? Thats cool. Could you let me know the
results of next weeks lottery please. Seriously you don't have the
slightest idea about wether we produce the right results or not, there's
not even code yet that can produce wrong results.

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

Thats exactly what we don't want. KDevelop shouldn't invent its own
buildsystem.

Andreas

-- 
Don't worry so loud, your roommate can't think.