Commit r1066661: "Make it possible to run kdevelop in gdb again"
zwabel at googlemail.com
Mon Dec 28 19:57:08 UTC 2009
Am Montag 28 Dezember 2009 19:53:47 schrieb Andreas Pakulat:
> But then I can try to debug problems with the session-specific duchain
> 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.
You can always debug the kdevelop startup doing:
KDEV_SESSION_ID=... gdb kdevelop
with the KDEV_SESSION_ID value read from "ls ~/.kdevduchain" or from the
debug-output that kdevelop gives on every startup. And you would _only_ need
that when debugging duchain-directory specific startup problems, for other
cases we could have a simple "--nofork" option. Btw, startup problems that are
specific to one duchain repository are very hard to debug anyway, as the whole
repository is wiped automatically after 2 crashes.
More information about the KDevelop-devel