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.
_______________________________________________
KDevelop-devel mailing list
KDevelop-devel kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel
|
