GSOC 2015

Maciej Poleski d82ks8djf82msd83hf8sc02lqb5gh5 at gmail.com
Fri May 29 11:22:46 UTC 2015


Dnia piÄ…tek, 29 maja 2015 01:07:39 Milian Wolff pisze:
> 
> Anyhow, the API is unstable, i.e. source-incompatible changes may be done, and 
> thus we cannot safely use it without hooking ourselves to a certain clang 
> version, which is cumbersome - we want to support multiple distros with 
> varying clang versions.
> 
> So overall, we go back to the initial idea - move tooling into a (collection 
> of) executables and call them from kdev-clang as required. If no executables 
> could be build (due to source incompatibilities), then the refactoring actions 
> are disabled.
> 
> Sounds good?

Sounds very easy.
The advantage of this solution is safety - errors in my code wouldn't crash the whole IDE, but on the other side it would make communication between KDevelop and tools a bit complicated. In case of some refactorings the idea is to collect some informations at the beginning, present them to the user (in GUI), receive decisions made by user and then invoke real refactorings. It also applies to initial selection of "applicable refactorings here".
My idea here was to check (during compilation of kdev-clang) if there are appropriate Clang libraries in the system and issue special definition if so (version or something like this). Most of Clang-dependent source code would be in special subdirectory compiled only if appropriate Clang was found, and glue-code outside of this subdirectory would use #ifdef to choose appropriate implementation (enabling or disabling the whole thing).

What about this idea?

> 
> Bye
> 

Best Regards
Maciej Poleski


More information about the KDevelop-devel mailing list