Can C++ support cope with changing include dirs?
apaku at gmx.de
Sat Feb 13 19:41:44 UTC 2010
On 13.02.10 20:17:06, David Nolden wrote:
> 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?
No, the build config might change defines and provide other include dirs
as well. I have various builddirs for this particular project I'm going
to use the custom-buildsystem-support for. Each builddir has completely
different setup, some use Qt3, some use Qt4+Qt3Support, some use
Qt4 without the Qt3 backwards compat. Some builddirs build additional
subcomponents which needs yet some other includedirs/defines etc.
> And right now we're not yet in the state of having to worry about
> being 'perfect' into the last detail.
I don't want to be perfect. I just want kdevelop to not throw up tons of
errors when I switch the build config and of course I also want it to
provide the right completion when switching from Qt3 to Qt4.
> 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.
Ok, can you give me a hint where to look for the latter part?
Good day for a change of scene. Repaper the bedroom wall.
More information about the KDevelop-devel