Refactoring CMakeProjectManager - threading revisited

[Milian Wolff]

On Monday 29 July 2013 03:41:36 Aleix Pol wrote:
<snip>
> Yes, we can try to do something like that, we have separated that data in
> the past in the CMakeProjectData tuple (since David had plans to serialize
> it, which never happened).

Yes, that would help a lot. Deciding whether a given folder should be a 
"ProjectBuildFolderItem" could be done purely based on whether it contains a 
CMakeLists.txt or not.

All the rest, i.e. finding out targets, defines and include paths should then 
be done in the background. Once the data is found there, pass it along to the 
foreground and add it to the proper data structures and add the target items. 
No mutexes required at all.

> Anyway, if you give me some time, I can look into moving the threading into
> the plugin, which I agree that could be of some benefit.
> That said, note that it will require some fundamental refactoring of the
> import API.

Yes, that would be awesome. I still think that the steps outlined in my email 
should give a good roadmap. 

When it comes to the refactoring of the import api, then yes - please do 
refactor it. The current way is simply broken anyways. "parse" e.g. is only 
used by CMake, and never returns anything there. The threaded ImportProjectJob 
also is only used by CMake. The others (i.e. AbstractFileManager, hopefully 
cmake will also use it eventually) just return a custom import job.

This is imo the way to go.

Bye

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