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

[Niko Sams]

On Tue, Dec 29, 2009 at 01:26, David Nolden <zwabel at googlemail.com> wrote:
> Am Dienstag 29 Dezember 2009 01:01:20 schrieb Andreas Pakulat:
>> 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?
>
> In the duchain library itself, in language-plugins, etc., there is many places
> where such objects are used as global statics, for example 'IndexedIdentifier
> globalImportIdentifier("import{....}");' or similar. When these objects are
> initialized, the duchain must already be initialized as well.
A naive idea: Allow creating IndexedString/IndexedIdentifier before a repository
is initialized by creating them in memory, and when the repository is created
copy them correctly into the repository.

> Ah yeah, and about the debugging problem, we could also simply add a "--gdb"
> option, that spawns a kdevelop instance with the correct environment variables
> set in gdb.
/me want's to use kdevelop for debugging :D


Niko