Project Filtering

[Milian Wolff]

On Thursday 25 July 2013 08:26:57 Andreas Pakulat wrote:
> Hi,
> 
> On Wed, Jul 24, 2013 at 10:13 PM, Milian Wolff <mail at milianw.de> wrote:
> > On Tuesday 23 July 2013 02:08:41 Milian Wolff wrote:
> > > Hey all,
> > > 
> > > I finally sat down to implement a generic project filter interface and
> > 
> > user
> > 
> > > configuration. I've published what I have so far in the projectfilter
> > > branch, please take a look.
> > 
> > I'm now considering merging this code into master - objections? Before
> > doing
> > so though, I have to figure out what to do with the current state of the
> > pseudo-threaded CMakeManager which breaks this new API...
> 
> What does 'break' mean here? Does the filtering not work 100% correctly or
> does it crash even more often? 

break == I did not implement it there as it would create new race conditions 
and random crashes since the IProjectFilter is not threadsafe. 

> In the latter case I think it would be
> better to first start the cmake-manager-refactoring and once its
> sufficiently advanced so that you know it'll be mergeable within a few
> weeks merge the filter branch into master. That way you don't break master
> for cmake users for an unforseeable amount of time. If its just the
> filtering thats not working all the time or so, its probably not as
> critical to wait for the cmake-refactoring. My concern is just that the
> refactoring can take quite some time and hence may be delayed for weeks or
> even months and having the filtering half/completely broken for so long
> means there can't be any releases...

We could merge the project filter and just don't show the config dialog for 
cmake (and not use the new code there). Then we can refactor the code until we 
eventually can use the project filter.

Alternatively we could use the ugly ForegroundLock hack to ensure thread-
safety for the filtering (but that's probably a very bad idea, performance 
wise).

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de