Review Request 123963: First bits of refactorings. Skeleton of interface for KDevelop. Build system. CompilationDatabase for CMake projects and ClangTool.

[Milian Wolff]

> On June 22, 2015, 10:32 p.m., Milian Wolff wrote:
> > refactoring/CMakeLists.txt, line 16
> > <https://git.reviewboard.kde.org/r/123963/diff/5/?file=380723#file380723line16>
> >
> >     no, using clang as a compile or as a library are two things. you are _not_ allowed to enforce clang as a compiler dependency here. we do want to keep support for compilation with GCC and any other compiler a user might want to apply.
> >     
> >     remove this comment please
> 
> Maciej Poleski wrote:
>     In fact we don't. User cannot freely use _any_ GCC version he wants. Only versions supporting C++11 are allowable. But support for C++14 is since GCC 5.1 and Clang 3.4. The former is brand new, almost nobody have this installed. The later is already a requirement. Having Clang already as a requirement is a rare situation in which we could relax some constraints on use of language features provided with tool which we now can handle them. That would make build process more predictable.
>     
>     But this is only idea to think in future. Such change would be too big to apply "just like that". It's nice observation that writing IDE we don't only have some compiler available - we have "this" compilare available and we could make use of it.

Maciej, please read all my comments. I'm pretty sure I said to you before that you are _not_ allowed to use C++14, but have to stick to C++11. Thus, Clang 3.4 cannot be the requirement. And really, from our experience targeting GCC and Clang the previous years, it's not a huge issue and I don't see any significant changes that would "make the build process more predictable".

Really, this is not part of what this GSOC is about - pleaes concentrate on getting some refactorings implemented.


- Milian


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123963/#review81685
-----------------------------------------------------------


On June 20, 2015, 9:26 p.m., Maciej Poleski wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123963/
> -----------------------------------------------------------
> 
> (Updated June 20, 2015, 9:26 p.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Repository: kdev-clang
> 
> 
> Description
> -------
> 
> First bits of refactorings.
> Skeleton of interface for KDevelop.
> Build system (really nasty, linked DSO has 18MiB).
> CompilationDatabase for CMake projects and ClangTool (with cache, but without cache updates).
> Interface is not frozen for now.
> 
> Currently building of refactorings is enabled only if Clang 3.6.x is found. In other case build system behaves exactly as current master.
> 
> Refactorings require some contextual informations about projects. I made draft of interface with should feature:
>  - Stable ABI - dlopen (or equivalent) a DSO and if succeed (binary is still compatible with Clang libraries ABI), dlsym (or equivalent) some functions which are to provide all refactorings features
>  - Prototypes (with some implementation) of functions constituting API between KDevelop and refactorings backend
>  - It may be considered to use Qt plugin system to provide implementation of this (or equivalent) interface. This would be more expensive, but also more portable
>  - In worst case this library (static version) can be used with additional driver to make stand-alone executable providing all refactorings features (but it would require additional marshaling and hamper cooperation with user (how to provide UI in such a case?))
> 
> Handling dependencies between Clang/LLVM libraries is a nightmare. I extended FindClang.cmake to find much more libraries and used them to link with first pieces of my code. This is huge, requires additional libraries like zlib and even ordering of dependencies can cause linker errors.
> 
> Interface is not finished
> 
> 
> Diffs
> -----
> 
>   CMakeLists.txt 875172a8407f4bd9faf330f032a280fa66c2b16f 
>   clangsupport.h 8ed1ec90bbbc41d7c7a94d926e0951c729a6194c 
>   clangsupport.cpp e22c55426a2e839ec11cbe0b2fe1e13721b0583a 
>   cmake/FindClang.cmake 6c9bd6ef0242319122dcc7e6fd6cea8d9f0cbfbb 
>   refactoring/CMakeLists.txt PRE-CREATION 
>   refactoring/DocumentCache.h PRE-CREATION 
>   refactoring/DocumentCache.cpp PRE-CREATION 
>   refactoring/NoopRefactoring.h PRE-CREATION 
>   refactoring/NoopRefactoring.cpp PRE-CREATION 
>   refactoring/Refactoring.h PRE-CREATION 
>   refactoring/Refactoring.cpp PRE-CREATION 
>   refactoring/RefactoringInfo.h PRE-CREATION 
>   refactoring/RefactoringInfo.cpp PRE-CREATION 
>   refactoring/RefactoringsGlue.h PRE-CREATION 
>   refactoring/RefactoringsGlue.cpp PRE-CREATION 
>   refactoring/interface.h PRE-CREATION 
>   refactoring/interface.cpp PRE-CREATION 
>   refactoring/utils.h PRE-CREATION 
>   refactoring/utils.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/123963/diff/
> 
> 
> Testing
> -------
> 
> Compiles on my Gentoo system. It makes sense to build this only on system with Clang 3.6.
> 
> 
> Thanks,
> 
> Maciej Poleski
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20150623/e6e2d60c/attachment.html>