Debugging KParts

[Adam Treat]

On Friday 04 February 2005 11:13 am, David Faure wrote:
> Hmm, what you want is something like KStandardDirs::addResourceDirs(
> "module", $builddir ), and addResourceDirs( "services", $srcdir ) to find
> the .desktop file if the part has never been installed, but the point is to
> do those things without modifying the source code, right?
>
> One solution would be to add some code to KStandardDirs::addKDEDefaults(),
> which reads from an env. var ($KDE_BUILDDIR?) set by kdevelop. Doesn't
> solve the problem for those who just run ./foo from a shell without using
> kdevelop though.
>
> So I'd rather see a solution like: adding a stat() in KStandardDirs to
> check if there's a Makefile in the same dir as the binary, read the srcdir
> and builddir from it, and add them to the correct resources.
> It sounds a bit fragile to rely on Makefile syntax, but I don't see another
> way to do it, which would work with srcdir!=builddir, except hacking
> libtool to pass one or two env vars for the first solution.

This doesn't solve the problem for those projects using other build tools 
though.  Granted, there probably aren't that much, if any, but why not check 
for a custom file ... say 'kparts.env' in the same dir as the binary.  Those 
who wish to debug kparts without installing can place one of these in their 
project no matter what build tool they are using.  KDevelop can automatically 
include one.  'kparts.env' could use standard ini format and include 
references to srcdir and builddir. 

> XMLGUI files are looked in the "data" resource but with a subdir named
> after the instance name, so that one would even need a
> KXMLGUIClient::setXMLFile hack (fallback by looking in current dir, if
> that's enough).