KDE/kdevplatform/language/duchain

[Hamish Rodda]

Hi,

On Friday 18 July 2008 20:06:14 Andreas Pakulat wrote:
> 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.

Surely we can re-engineer this so that the Core instantiates DUChain, rather 
than it being its own global static... problem solved? (ICore::self()-
>duchain())

Cheers,
Hamish.