Can C++ support cope with changing include dirs?

[David Nolden]

Am Mittwoch 10 Februar 2010 16:01:50 schrieb Andreas Pakulat:
> On 10.02.10 15:12:29, David Nolden wrote:
> > Am Samstag 06 Februar 2010 08:41:55 schrieb Andreas Pakulat:
> > > for the custom buildsystem support I'm working on, I'd like to add a
> > > builddir-switcher to the project tree. The idea is to make it easy to
> > > switch between different builddirs of the same source tree (in my
> > > particular case I have 2-4 builddirs with different Qt libs and
> > > different features in the project turned on).
> > >
> > > The thing I'm not sure about: Is the C++ support able to work with
> > > that? I'm concerned about wether or not there's a way to let it reparse
> > > all files when the includes and/or defines changed and wether the
> > > DUChain is able to handle this properly, so that it doesn't have to
> > > completely reparse everything once I've enabled all builddirs at least
> > > once.
> > >
> > > Obviously I want things such as code-completion of non-project classes
> > > work properly once I've changed builddirs.
> > >
> > > Or am I better off using separate sessions for each builddir (which
> > > would suck royally, but well...)?
> >
> > Theoretically this could be done through the environment-management,
> > where each chosen build-configuration would be a statically different
> > environment. It would mean that the duchain would contain several copies
> > of the data, one for each environment aka. build-dir.
> >
> > The same problem applies to the build-dirs in the cmake support, so maybe
> > it would be good to encode this whole problem as "Configurations", and
> > then let the c++ support create duchain copies based on configuration.
> 
> Sounds like a plan, and yes I was thinking about cmake builddirs too and
> hence expose this via the buildsystem API. Can you point me towards the API
> that I need to use to tell DUchain that such a Configuration switch
> happened?

There is no such API.

Actually, thinking about the whole thing again, I feel this is not KDevelop 
4.0 material. After all, the actual source-code that is used should be the 
same in all configurations, no? And right now we're not yet in the state of 
having to worry about being 'perfect' into the last detail.

A simpler solution for now is: Just let the build-manager return the correct 
include-paths depending on the current configuration, and additionally put a 
switch somewhere into the UI to reparse the whole project using the already 
existing ProjectParseJob like after startup.

Greetings, David