Commit r1066661: "Make it possible to run kdevelop in gdb again"

Andreas Pakulat apaku at
Tue Dec 29 00:01:20 UTC 2009

On 28.12.09 20:57:08, David Nolden wrote:
> Am Montag 28 Dezember 2009 19:53:47 schrieb Andreas Pakulat:
> > But then I can try to debug problems with the session-specific duchain
> > directory.
> > 
> > I'm starting to think that having the duchain in static code loaded
> > before everything else is the real problem here. If that wasn't the case
> > we wouldn't need this obscure env var and any extra process.
> That would also mean that one couldn't use "IndexedIdentifier", 
> "IndexedString", and all such duchain types statically, which would be a 
> significant limitation for such cosmetic reasons.

Can you explain in more detail what limitation that is? I still can't
see why we need all these things set up even before main() is entered,
there's no code using any of these classes until at least the Core is
created. So Core::initialize() should be early enough for the creation
and initialization of the DUChain no?

> You can always debug the kdevelop startup doing:
> KDEV_SESSION_ID=... gdb kdevelop
> (gdb) run

Thats quite inconvenient IMHO, especially when working with multiple
sessions there's currently no way to find out the right one.


You may be infinitely smaller than some things, but you're infinitely
larger than others.

More information about the KDevelop-devel mailing list