Brainstorming the debugger problem

Benoit Cerrina Benoit.cerrina at
Wed Mar 22 08:11:15 UTC 2000

from my experience at work I'd say it would certainly be nice to be able to
set up
another path for the output files (executable and libraries) as well as the
secondary files (object files) especially in case of multiplatform
If a program is developped for several platforms either through cross
compilation or using different machine and an NFS workspace directory it
would be necessary.
In our case a directories at the workspace level called
are created to hold the "runtime view" i.e. all the runtime directory
structures, executables, libs, data files...

In any case, as long as the project management is being rethought I'd
suggest that this type of options should be made available.
One way to do this would be to define an xml format which would contain the
specifics of a type of workspace organisation structure.  New one could be
added easily and the appropriate and other automak and autoconf
script could be generated.


----- Original Message -----
From: "Ralf Funken" <rfunken at>
To: <kdevelop-devel at>
Sent: Monday, March 20, 2000 7:30 AM
Subject: Brainstorming the debugger problem

> Hi,
> I think we agree that the key problem is to find out where the executable
> so we can call the debugger with it. Maybe it's not so difficult to find
> after all. As far as I can see there are only two posssibilities: either
> in the projekt dir or in .libs. If it is in .libs, there's a shellscript
> the same name in the project dir. If the user later decides not to link
> so's we have exe's in both paths. Now the idea is the following. If we
> the debugger via a slot ( I didn't have the time to check this) , we had
> chance to check the magic number of the file before we call the debugger.
> first check the file in the project dir( the user might have redecided not
> link against so's but this always reflects the actual setting). If  the
> is "#!" ( you know that this is the magic number in ascii for  shell
> 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 ...
> Ralf
> --
> Ralf Funken
> The KDevelop Project
> Email: rfunken at

More information about the KDevelop-devel mailing list