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

[David Nolden]

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.

And it is very convenient code-wise to do this, as else, all these places 
would require explicit initialization in an "init()" like fashion, which is 
ugly, as it requires additional code to do the initialization, instead of just 
relying on the standard c++ initialization of global statics.

Some of these objects have been turned into static functions, which partially 
solves the problem, but sucks in its own right, because something as simple as 
just reading out a simple integer is being turned into a function-call, which 
may really hurt when used very frequently.

Well, I guess in future we can review this at some point to see whether we can 
find a compromise between code-convenience and a better controlled 
initialization order, but right now I think it is not worth the hassle.

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.

Greetings, David