<div class="gmail_quote">On Wed, Sep 21, 2011 at 4:47 PM, Alexandre Courbot <span dir="ltr"><<a href="mailto:gnurou@gmail.com">gnurou@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Hey,<br>
<br>
Thanks for the feedback - glad you found my article heartwarming.<br>
KDevelop is definitely a project one can be proud about. And yes, I<br>
think with a few patches here and there it could become a great tool<br>
for kernel hackers, especially beginner ones. It surely helped me a<br>
lot already.<br>
<br>
I will post my reply to Milian here, where I propose we continue the discussion.<br>
<br>
a) Isn't the generic project manager independant of make? Why would it<br>
need to run it in this case?<br></blockquote><div>It tries to figure out some include directories by calling a null gcc, maybe that's the problem?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


<br>
b) I thought it would make sense to have the automatically included<br>
files into .kdev_include_paths since it would allow to restrict the<br>
inclusion to some parts of a project. For the kernel project-wide<br>
settings are fine, but as far as the generic project manager is<br>
concerned we may as well try to be, well, generic. :p It seems,<br>
looking at the code, that these files can already hold other stuff<br>
(did not figure out what yet though), but if you think project wide<br>
settings are better, I'm fine with that too.<br>
<br>
c) I wonder how far could Makefiles parsing could go for guessing -D<br>
parameters (especially if some variables need to be expanded). If this<br>
works, the same thing could be done for -include too. But letting the<br>
user specify these manually (along with a "guess from Makefile" button<br>
seems safer.<br></blockquote><div><br></div><div>it's what I said on A. I'm not sure what you're going for, though. In an ideal case, one would never need to add include directories.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


<br>
d) Yep, although a C++ parser, KDevelop's parser (unsurprisingly) does<br>
a great job with C - even kernel C. Here I guess being liberal is ok,<br>
as long as it "just works". I will try to get the C99 initializations<br>
in after I understand the parsing/DUchain stuff.<br>
<br>
I will also try to get the massif metrics you asked (I already use Git<br>
version). As for memory consumption, parsing the parts of the code I<br>
have specified in the article + a couple of drivers results in around<br>
1GB of memory used, with a good dozen of files opened. By today<br>
standards, this seems very acceptable and much better than e.g.<br>
Eclipse anyway. Of course, if you want to parse the whole kernel tree,<br>
this is another story. The parser would take too much time anyway to<br>
make this practical, but this is not a real concern. Lookup is just<br>
fast. Sometimes reverse lookup takes more time than I would expect,<br>
but this is also the case in Qt projects so nothing like a scaling<br>
problem.<br>
<br>
All in all KDevelop looks pretty fun to work on. In my student days I<br>
did quite a lot of static code analysis/optimization/specialization,<br>
so maybe I could also give a hand there, if time allows (which I<br>
unfortunately doubt). But first I'd like to fix these few things -<br>
after all, KDevelop is my main work tool, so I'd better shape it right<br>
for me. ;)<br>
<div><div></div><div class="h5"><br>
Alex.<br>
<br>
--<br>
KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kdevelop.org">KDevelop-devel@kdevelop.org</a><br>
<a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
</div></div></blockquote></div><br>