More problems using kdevelop 2.1.3

[Alistair Mann]

Thus spaketh falk.brettschneider at gmx.de on Sunday 17 November 2002 10:22 pm:
> Dieter Landolt wrote:
> >Hallo
> >
> >Does eny one know, about such problems with kdevelop, respectly knows how
> > i can fix this ?
> >
> >1. If i click to an error message after compile, the curser shuld position
> > to the error in the source file.
>
> This is fixed in KDevelop-2.1.4 that will be released with the upcoming
> KDE-3.0.5.

This inspires me to write.

I've been using KDevelop 2.1.3 for work for some time, and have found it 
astonishingly useful -- I want those who work on it to know how much I 
appreciate the value of a good IDE!

I notice some minor problems: I'll relay them and my workarounds here if for 
no other reason than someone might google them eventually.

System: kdevelop 2.1.3, kde 3.0.3, qt 3.0.4 (kernel 2.4.18 on Dell Inspiron 
8100)

1). Problem: In Tab page mode, every so often a clicked-to tab will fail to 
render the source at all. 
Replication: Not been able to, seems random. Can supply screen grab if someone 
would like it though, as it happens several times a day.
Workaround: clicking away from the tab then back again will render properly.

2). Problem: Distclean/Rebuild will runaway, apparently indefinitely. 
Replication: 
Open new C++ project, default options
f7 | Make Options
 check 'Print Debug Information'
 check 'Touch files'
(allow configure to rerun)
Distclean/ Rebuild all
make returns lots of "Trying pattern rule on ...". 
Loop requires alt-f4 close or KILL signal to terminate

Fix
touch * (in source directory)
touch * (in project directory)
make distclean (at command line, not in kdevelop, in project dir)
reload kdevelop, remove above make options
allow configure to rerun
Distclean/ Rebuild all now works okay.

3. Problem: debug #1
Occasionally, on starting debug the statusbar will say "No such file as 
main.cpp" (there is), breakpoints will continue to be blue rather than red, 
and breakpoints there and elsewhere will not be honoured. Afflicts files both 
registered and unregistered.
Replication: unable to do so -- happens every so often
Workaround: Lots of debug statements to stdout ;-)

4. Problem: debug #2
Occasionally, although breakpoints are properly marked in red, the green arrow 
marking current line will not show up. The breakpoint is effective though.
Workaround: first line in call stack tab will normally indicate line number at 
which the green arrow would show.
REQUEST: could the line number I refer to be shown at the start of the line 
rather than at the end? ie, as "#0 main (at main.cpp:26)(argc = ....)"
I've not been able to replicate this on-demand.

5. Problem: debug #3
Occasionally, although breakpoints are properly marked in red, the effective 
breakpoint is several lines away. This has so far always occured when the 
green arrow is missing entirely, so may be related to debug #2 above.
I've not been able to replicate this on demand.
Workaround: looking at the watch tab alot.

None of the above have been very critical, just irritating.

Thanks again all, and best wishes with Gideon!
-- 
Alistair Mann

-
to unsubscribe from this list send an email to kdevelop-request at kdevelop.org with the following body:
unsubscribe »your-email-address«