[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop-bugs
Subject:    [Bug 172622] New: Better cooperation with LLVM/clang community
From:       Pantelis <pktoss () gmail ! com>
Date:       2008-10-11 18:50:06
Message-ID: bug-172622-40295 () http ! bugs ! kde ! org/
[Download RAW message or body]

http://bugs.kde.org/show_bug.cgi?id=172622

           Summary: Better cooperation with LLVM/clang community
           Product: kdevelop
           Version: unspecified
          Platform: Compiled Sources
        OS/Version: unspecified
            Status: UNCONFIRMED
          Severity: wishlist
          Priority: NOR
         Component: general
        AssignedTo: kdevelop-bugs@kdevelop.org
        ReportedBy: pktoss@gmail.com


Version:            (using Devel)
Installed from:    Compiled sources

LLVM is a very decent compiler framework providing a JIT, an intermediate
representation and various assorted goodies. Relatively recently they decided
that they would really like to have a frontend too that is:

     * Faster than gcc (up to much faster)
     * Implemented in readable C++ and available as separate libraries
     * Well documented and supported.

They already have an (almost) 100% conformant preprocessor available as a
separate library and parsers for C and ObjC and a tiny bit of C++.

Both LLVM and clang (the frontend) are BSD licensed.
clang is already being used to implement various static analysis tools for C
code
and is starting to gain in popularity.

Kdevelop has a nice C++ parser which is something clang probably won't have
perhaps for a couple of years even though they started attracting contributors
like e.g., doug gregor and IIRC members of the boost community.

It seems to me that there exists a great opportunity here for the kdevelop
community to interact more closely / join forces with LLVM/clang to
create the 'best C/ObjC/C++ parser ever' at least for IDE purposes.
Since most/all of the clang contributors are compiler people this could
help with kdevelop's manpower issues at least in this front.

Clang is also IIRC intended to be embedded on an IDE (XCode) at least
eventually
so changes requested by kdevelop to e.g., have better incrementality in parsing
or multiple threads or whatever will probably be accepted in clang.

Also, clang and kdevelop's parser have pretty similar design, clang devs
actually seem to have looked at kdevelop's parser sources but discarded it
because it had no comments and thus was hard to understand and evaluate. But
with the help of kdevelopers that could change :)

This is all just IMHO, but modern IDE problems (static/dynamic
analysis/refactoring) are pretty hard, so it helps to have as large a community
as possible to stay competent.


-- 
Configure bugmail: http://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

_______________________________________________
KDevelop-bugs mailing list
KDevelop-bugs@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-bugs
[prev in list] [next in list] [prev in thread] [next in thread]