Can C++ support cope with changing include dirs?

Aleix Pol aleixpol at kde.org
Sat Feb 13 20:00:37 UTC 2010


we could just reload the project whenever the build directory has changed.
That would be the easy solution at least.

On Sat, Feb 13, 2010 at 8:17 PM, David Nolden <zwabel at googlemail.com> 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? 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
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100213/2202319f/attachment.html>


More information about the KDevelop-devel mailing list