Re: KDE/kdevelop/languages/cpp

On 26.06.07 11:20:18, David Nolden wrote:
> On Tuesday 26 June 2007 02:29:01 Matt Rogers wrote:
> > On Jun 24, 2007, at 3:19 PM, Kris Wong wrote:
> > > SVN commit 679743 by wongk:
> > >
> > > Ported IncludePathResolver from KDevelop 3.
> >
> > I'm not sure this will be/is needed anymore. The
build systems should
> > provide the locations to search for includes.
We've added mechanisms
> > to the build managers specially for this. Even the
custom makefile
> > manager should know how to at least parse the
Makefile to get this
> > information even if it doesn't allow editing it.
> >
> > Taking that information into account, are there
other places where
> > this might be used?
> 
> Yes, with files that are not part of any project, and
for debugging the 
> build-system include-path computing algorithms.

I don't see how the include-path-resolver can help here.
IIRC it was
here, though not sure, that somebody posted a way to ask gcc
for its
standard include dirs. That can be done when editing files
outside any
project. After all thats all the paths you can find out
about, without
having the user give you some more paths.

Unless of course the include-path-resolver does more than
just finding
the include-paths for a given dir.

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

Whats the problem with cmake-generated Makefile's? Yes, its
not
dead-easy to parse these as you have to "follow"
forwards and such, but
I don't think thats impossible to parse cmake-generated
makefiles.

Andreas

-- 
You have been selected for a secret mission.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

>> Yes, with files that are not part of any project,
and for debugging
>> the build-system include-path computing
algorithms.

> I don't see how the include-path-resolver can help
here. IIRC it was
> here, though not sure, that somebody posted a way to
ask gcc for its
> standard include dirs. That can be done when editing
files outside any
> project. After all thats all the paths you can find out
about, without
> having the user give you some more paths.

Yes, someone posted something along these lines.  KDevelop 3
also does
this.  It is currently a TODO.

> Unless of course the include-path-resolver does more
than just finding
> the include-paths for a given dir.

It looks for a Makefile in the source directory and runs an
appropriate
make command to get the include paths.

> 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 gives the ability to have include paths for moving
forward on cpp
support w/o having to hard code something until the build
managers are
capable of returning this information.  Once we reach this
point, we can
easily re-evaluate wether this is necessary or not.

Kris Wong

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Tuesday 26 June 2007 11:59:32 Andreas Pakulat wrote:
> On 26.06.07 11:20:18, David Nolden wrote:
> I don't see how the include-path-resolver can help
here. IIRC it was
> here, though not sure, that somebody posted a way to
ask gcc for its
> standard include dirs. That can be done when editing
files outside any
> project. After all thats all the paths you can find out
about, without
> having the user give you some more paths.
>
> Unless of course the include-path-resolver does more
than just finding
> the include-paths for a given dir.

That command only finds global standard include dirs 
like /usr/include, /usr/include/c++/4.0.1 etc., but not
include-dirs defined 
by the build-system, like for example the qt
include-directory.

KDevelop-4's code-completion will highly depend on having
all include-files 
parsed, so only parsing those in global include-dirs would
result in useless 
code-completion.

The include-path resolver finds, when successful, all
include-paths defined by 
the underlying build-system.

> > 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.
>
> Whats the problem with cmake-generated Makefile's? Yes,
its not
> dead-easy to parse these as you have to
"follow" forwards and such, but
> I don't think thats impossible to parse cmake-generated
makefiles.
>
> Andreas

Why not discuss this once there is an alternative? Currently
there is none.. I 
cannot test code-completion in realistic environments
without correct 
include-paths.

greetings, David


_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 26.06.07 07:56:35, Kris Wong wrote:
> > Unless of course the include-path-resolver does
more than just finding
> > the include-paths for a given dir.
> 
> It looks for a Makefile in the source directory and
runs an appropriate
> make command to get the include paths.

As I said to David already, this breaks with out-of-source
builds or
buildsystems that don't use makefile "under the
hood". So the argument
"getting include paths for non-project files" is
more or less moot.

> > 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 gives the ability to have include paths for moving
forward on cpp
> support w/o having to hard code something until the
build managers are
> capable of returning this information.  Once we reach
this point, we can
> easily re-evaluate wether this is necessary or not.

Did you talk to David? His answer is nearly the same and
neither you nor
him did answer my question. I was just asking wether he or
you knows of
stuff in cmake-generated (or other) Makefile's that can't be
parsed and
interpreted by anything other than make itself.

Andreas

-- 
You're definitely on their list.  The question to ask next
is what list it is.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

> As I said to David already, this breaks with
out-of-source builds or
> buildsystems that don't use makefile "under the
hood". So the argument
> "getting include paths for non-project files"
is more or less moot.

I wasn't trying to make an argument, just stating what it
did.

> Did you talk to David? His answer is nearly the same
and neither you
nor
> him did answer my question. I was just asking wether he
or you knows
of
> stuff in cmake-generated (or other) Makefile's that
can't be parsed
and
> interpreted by anything other than make itself.

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?

Kris Wong

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

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.ma
ke 
languages/cpp/CMakeFiles/kdevcpplanguagesupport.dir/cppcodec
ompletionmodel.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



_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 26.06.07 15:43:45, David Nolden wrote:
> 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.

There already is a Makefile parser in KDevelop4's custom
makefile
manager. Although its only use is fetching targets from a
Makefile.

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

Sure. I completely agree. In case nobody noticed: I wasn't
expecting you
or Kris to drop that thing right away, I know you need that
to make
duchain/code-completion/.... work. All I said was that your
points of
cmake-generate Makefile's and non-project-files are not good
arguments
for having the include-path resolver. The only good and
perfectly valid
argument is that there's no other way currently to find out
about
include paths.

Andreas

-- 
Everything that you know is wrong, but you can be
straightened out.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Tuesday 26 June 2007 16:12:04 Andreas Pakulat wrote:
> On 26.06.07 15:43:45, David Nolden wrote:
> Sure. I completely agree. In case nobody noticed: I
wasn't expecting you
> or Kris to drop that thing right away, I know you need
that to make
> duchain/code-completion/.... work. All I said was that
your points of
> cmake-generate Makefile's and non-project-files are not
good arguments
> for having the include-path resolver. The only good and
perfectly valid
> argument is that there's no other way currently to find
out about
> include paths.
>
> Andreas

And this is my point: 
I think, even when every build-system we have perfectly
computes the 
include-paths, we still need a way to get include-paths for
files that are 
within no configured project, whereby I don't mean external
files included by 
a project, but files that are completely independent. We
cannot do it 
perfectly, but the include-path-resolver at least works for
most cases on 
unix(especially for the still most common automake-bases
projects).

The use-case:
My video-driver has a bug, I download the source using
apt-get source, compile 
it, open a file with kdevelop, can comfortably navigate the
code, get 
code-completion, find the error, fix it, ready.

That's something I wouldn't do with kdevelop now, because it
needs too much 
setup. That's why I want decent code-completion without any
setup in 
kdevelop-4. It surely won't work for all cases, but if it
works for most 
cases, and especially for the most simple cases, it would be
ok to me.

greetings, David


_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel