we could just reload the project whenever the build directory has changed.<br>That would be the easy solution at least.<br><br><div class="gmail_quote">On Sat, Feb 13, 2010 at 8:17 PM, David Nolden <span dir="ltr"><<a href="mailto:zwabel@googlemail.com">zwabel@googlemail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Am Mittwoch 10 Februar 2010 16:01:50 schrieb Andreas Pakulat:<br>
<div><div></div><div class="h5">> On 10.02.10 15:12:29, David Nolden wrote:<br>
> > Am Samstag 06 Februar 2010 08:41:55 schrieb Andreas Pakulat:<br>
> > > for the custom buildsystem support I'm working on, I'd like to add a<br>
> > > builddir-switcher to the project tree. The idea is to make it easy to<br>
> > > switch between different builddirs of the same source tree (in my<br>
> > > particular case I have 2-4 builddirs with different Qt libs and<br>
> > > different features in the project turned on).<br>
> > ><br>
> > > The thing I'm not sure about: Is the C++ support able to work with<br>
> > > that? I'm concerned about wether or not there's a way to let it reparse<br>
> > > all files when the includes and/or defines changed and wether the<br>
> > > DUChain is able to handle this properly, so that it doesn't have to<br>
> > > completely reparse everything once I've enabled all builddirs at least<br>
> > > once.<br>
> > ><br>
> > > Obviously I want things such as code-completion of non-project classes<br>
> > > work properly once I've changed builddirs.<br>
> > ><br>
> > > Or am I better off using separate sessions for each builddir (which<br>
> > > would suck royally, but well...)?<br>
> ><br>
> > Theoretically this could be done through the environment-management,<br>
> > where each chosen build-configuration would be a statically different<br>
> > environment. It would mean that the duchain would contain several copies<br>
> > of the data, one for each environment aka. build-dir.<br>
> ><br>
> > The same problem applies to the build-dirs in the cmake support, so maybe<br>
> > it would be good to encode this whole problem as "Configurations", and<br>
> > then let the c++ support create duchain copies based on configuration.<br>
><br>
> Sounds like a plan, and yes I was thinking about cmake builddirs too and<br>
> hence expose this via the buildsystem API. Can you point me towards the API<br>
> that I need to use to tell DUchain that such a Configuration switch<br>
> happened?<br>
<br>
</div></div>There is no such API.<br>
<br>
Actually, thinking about the whole thing again, I feel this is not KDevelop<br>
4.0 material. After all, the actual source-code that is used should be the<br>
same in all configurations, no? And right now we're not yet in the state of<br>
having to worry about being 'perfect' into the last detail.<br>
<br>
A simpler solution for now is: Just let the build-manager return the correct<br>
include-paths depending on the current configuration, and additionally put a<br>
switch somewhere into the UI to reparse the whole project using the already<br>
existing ProjectParseJob like after startup.<br>
<br>
Greetings, David<br>
<div><div></div><div class="h5"><br>
--<br>
KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kdevelop.org">KDevelop-devel@kdevelop.org</a><br>
<a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
</div></div></blockquote></div><br>