Brainstorming the debugger problem
tasin at e-technik.fh-muenchen.de
Mon Mar 20 12:03:26 UTC 2000
Ralf Funken wrote:
> I think we agree that the key problem is to find out where the executable is,
> so we can call the debugger with it. Maybe it's not so difficult to find out
> after all. As far as I can see there are only two posssibilities: either it's
> in the projekt dir or in .libs. If it is in .libs, there's a shellscript with
> the same name in the project dir. If the user later decides not to link against
> so's we have exe's in both paths. Now the idea is the following. If we called
> the debugger via a slot ( I didn't have the time to check this) , we had the
> chance to check the magic number of the file before we call the debugger. We
> first check the file in the project dir( the user might have redecided not to
> link against so's but this always reflects the actual setting). If the number
> is "#!" ( you know that this is the magic number in ascii for shell scripts)
> we use the file in .libs. If not we call the debugger with the exe in the
> project dir.
> I told you it was brainstorming, so if the idea is absolutely BS ...
I agree... it isn't that difficult to decide where the executable
I can see only these two possibilities (apart from Falk's suggestion,
which breaks the automake/autoconf stuff and would cause many
changements inside KDevelop 1.x, IMHO too much for the "last" 1.x
version - sorry Falk ;-))
BTW: It is only for debugging _uninstalled_ binaries... so I see only
binaries created inside project-subdir or project-subdir/.libs... am I
Ok... it isn't the perfect way, because we would need to parse the
Makefile where the build directory would be, which can differ from the
source dir, but KDevelop didn't support this, so I think we wouldn't
break anything which isn't already broken ;-).
But to make "nails with heads" (like germans say :-)))) I committed a
version which should handle this problem...
PS: let me know if this is the way you wanted to get it handled...
oohhh sveglia.... il mondo e' ammalato, ma x colpa di chi.........
:-------W. Tasin, FB
<Key-Fingerprint: 1610 835F 0080 32F4 6140 6CF7 A7D0 44CD 7961A645>
More information about the KDevelop-devel