KDE/kdevplatform/language/duchain

[Andreas Pakulat]

On 17.07.08 23:22:13, Andreas Pakulat wrote:
> On 17.07.08 23:00:13, David Nolden wrote:
> > Looking at the log, it's obvious that the duchain is loaded before anything 
> > else, and that's the cause of the problem.
> 
> The problem is you're using a global static for something, and those get
> initialized before anything else. In particular before main() is run.
> However our executable gets linked to kdevplatformlanguage and thus the
> global static gets created before main() is run and so before our
> component data is created.
> 
> Long story short: You can't create global statics that need
> KComponentData in one of our libs.

Moving over to the devel list, maybe others have more/other ideas.

So I've digged around a bit about the problem. Basically David needs
KStandardDirs::locate("data") to work properly (for the place where to
store our persistent duchain) and KLockFile to do some locking. 

The problem is, due to shell linking against the language library the
global statics of the language library are initialized before main() is
run. Those statics contain code that needs KStandardDirs/KLockFile to
work - hen-egg-problem here.

KlockFile can be used without the main component data being setup, it
has a constructor to pass a component data, so language library can just
keep one of her own for that. However KStandardDirs doesn't work without
the main component of the application being setup. And one can't change
that once its created and set as main component. 

There's one other way (short of just using $HOME/.kdevduchain which
isn't quite that bad), but I'm not sure its possible: Separate the code
that needs the global statics from the code thats needed by shell. I
only had a quick look but apparently mostly backgroundparser and the
ilanguagesupport class are needed for the stuff that shell does with
language support. So I'm asking our language experts wether its
possible/feasible to move these out of the language library into a
separate library that doesn't link against the language library. This
way the language library would only be loaded once there's actually a
language plugin loaded and the main component has long been created.

Andreas

-- 
Your boss is a few sandwiches short of a picnic.