Integration with LLVM/clang

[JohnBaptist]

Hello there. I was wondering if there are currently any plans to integrate Code::Blocks into the LLVM/clang modular compiler framework. It seems to me that it would be great to take advantage of its static analysis and debugging features in an IDE like Code::Blocks. If there is already such an effort underway, I'd love to contribute. If not, I think we (meaning me and you and other people) should get cracking on this. I have a hunch that five years from now we'll all be using LLVM, and gcc will be a distant memory. Who's with me?

This post might perhaps more properly belong in the section for developers.

J

[stahta01]

I suggest posting a link to download a working compiler.
And stating what OS it requires.

Tim S.

[JohnBaptist]

Okay, as you wish.

LLVM/clang currently works on most of the more popular *nix variants. It's shipped by default with MacOS X 10.6 (and is the current recommended compiler). It's available as a binary download in the Ubuntu repositories. The FreeBSD project has recently decided to use it as its primary compiler for all ports and the kernel, totally replacing gcc. It may be available in repositories for other operating systems as well. It also allegedly works under Windows, but I haven't tested this.

The official web page is here: http://clang.llvm.org/
Information about building from source is here: http://clang.llvm.org/get_started.html
A comparison (biased, obviously, but fairly objective) with gcc is here: http://clang.llvm.org/comparison.html

From my perspective as a developer, LLVM/clang offers a lot of advantages over the gcc suite. It has much more advanced static analysis features and better error reporting. It's capable of graphically showing flow control errors (for example, a function that should but doesn't return a value), as is currently done in XCode. It compiles faster than gcc, uses less memory, and produces faster code.

From the perspective of a developer of IDEs, LLVM/clang is also easier to work with than gcc, since it provides its services through a well-defined, modular API. So, using it could theoretically reduce the duplication of effort that an IDE like Code::Blocks must do, to, for example, parse source code. Instead of parsing it itself, it could just rely on the compiler's parser engine to provide parsed data.

To be honest, I think this is the way forward. gcc has been around forever and is a great compiler but it's monolithic and crufty and isn't going to solve any of its severe design problems. I think we would be remiss if we didn't develop an IDE for *nix platforms that takes advantage of LLVM/clang. If there is no current project to do this, I would like to assemble a team to work on a branch of Code::Blocks with this end in mind. Any takers?

[oBFusCATed]

Have you tested the C++ part of clang? Can someone compile boost or any other mega hyper giga c++ project with it?
Most of the people here are interested in c++. An c++ is not the top priority for Apple, the main driving force behind llvm/clang.
Last time I've checked c++, wasn't supported at 100% .

But for one thing you're right, there is no need to rewrite the c/c++/objc/objc++ parser for the various code completion/refactoring tools needed by the IDE.
Clang some day will provide them and they would have been tested and working and fast. So any IDE can benefit from their work.

Another thing to have in mind is the license compatibility between C::B and clang -> GPL3 and the LLVM license.
Are they compatible? Can C::B link to llvm/clang libs?

I don't understand licenses much, so I can't tell, we need a lawyer or someone who understands the GPL.

If your desire is to use clang as compiler it should be fairly easy (I think), because they try to be compatible to gcc, so the migration is easier for developers.

Best regards...

[JohnBaptist]

The C++ part of clang works fine based on my non-thorough experiments. I don't know if it works with Boost or the STL yet, but this being worked on, and the fact that work is not complete shouldn't dissuade us from implementing support for the compiler in Code::Blocks. We should get started now, so that when it is finished, this will be the first fully *nix-based IDE that fully supports LLVM/clang.

Yes, clang has a drop-in gcc replacement front-end, so that all projects that assume gcc can work with clang with no modifications. That should work with Code::Blocks as-is. However, I'd like to extend Code::Blocks to take advantage of the more advanced features of clang. Take a look at the following screen shot (from http://developer.apple.com/mac/library/featuredarticles/StaticAnalysis/index.html):

http://developer.apple.com/mac/library/featuredarticles/StaticAnalysis/Art/uninitialized.jpg

It would be nice if the Code::Blocks GUI supported that kind of static analysis. I have long-standing resentment of Mac users and I would be deeply grieved if they were allowed to have a superior development environment.

clang is distributed on the BSD license, which is compatible with GPL insofar as GPL projects may incorporate BSD projects (but not the other way around). There are lots of similarly-licensed projects that have no problem co-existing with GPL projects. So, yes, Code::Blocks can certainly link to LLVM/clang modules and so forth.

[stahta01]

The C++ part of clang works fine based on my non-thorough experiments. I don't know if it works with Boost or the STL yet, but this being worked on, and the fact that work is not complete shouldn't dissuade us from implementing support for the compiler in Code::Blocks. We should get started now, so that when it is finished, this will be the first fully *nix-based IDE that fully supports LLVM/clang.

Feel free to start work on an Compiler Plugin using LLVM, I see no reason till I can use LLVM to compile C++ code under windows. The debug plugin is what is normally hard for new compiler support.

My testing on windows has "Hello World" failing. Might be an option issue, but I think some thing is missing/wrong with Compiler/Library under windows.

Tim S.

[heromyth]

That's a great idea. I think I can do something as your whish. A long time ago, I hacked CB a little
My main programming langs are C/C++/D, and the OS are WinXP SP3 and FreeBSD.

I think I can take some tasks from this project. You can contact me via e-mail:zxpmyth at yahoo.com.cn

[Kazade]

Another thing to have in mind is the license compatibility between C::B and clang -> GPL3 and the LLVM license.
Are they compatible? Can C::B link to llvm/clang libs?

I don't understand licenses much, so I can't tell, we need a lawyer or someone who understands the GPL.

I'm no lawyer, but Clang is released under the BSD license which is more liberal than GPL and so compatible. There would be no issue with C::B linking to it.

Clang could help with both code completion AND static code analysis (e.g. underlining errors in red). I think if C::B got in early and started integrating Clang NOW then when Clang is feature complete, Code Blocks would have unmatched code completion and syntax checking in C++. If I had the time, I'd start implementing plugins for this. But I would recommend that those guys working on code completion start looking at providing a Clang "backend" for it.

[stealthpaladin]

Integrating with LLVM would also give C::B more flexibility with Open CL developers (especially those coding in C++, which needs more developer support right now!) That's why I got to this topic today, isn't there some kind of file that could be edited to at least rig it together for now?

[bluephoenix]

Has there been any process on this?
Is a plugin available?

[killerbot]

a couple of hours ago I was attending a talk at fosdem about LLVM/clang.

Interesting I heard was, that the gcc options are also supported (well some might be lacking).

I made a little duplication of the gcc settings and changed the compiler executables, and I could build the CB generated console application.

So I am going to add a test support for it in CB, all catches or hints are very welcome.

I did notice already one drawback, seems the moment I activate the stdC++0x option, it no longer compile the simple console application (hello world) , it blocks with errors on its own header files. :-(

Question : what is the replacement for the archiver "ar' ?

[flebber]

I don't know if it works with Boost or the STL yet, but this being worked on, and the fact that work is not complete shouldn't dissuade us from implementing support for the compiler in Code::Blocks. We should get started now, so that when it is finished, this will be the first fully *nix-based IDE that fully supports LLVM/clang.

http://blog.llvm.org/2010/05/clang-builds-boost.html

[Justin Brimm]

From my perspective as a developer, LLVM/clang offers a lot of advantages over the gcc suite. It has much more advanced static analysis features and better error reporting. It's capable of graphically showing flow control errors (for example, a function that should but doesn't return a value), as is currently done in XCode. It compiles faster than gcc, uses less memory, and produces faster code.

LLVM/Clang certainly compiles faster than GCC and uses far less memory, but the resulting binaries are definitely not faster than what GCC can produce. As an example, here's a series of tests run on the binaries produced by GCC and LLVM. The graphs can be a little confusing as they mix graphs with different measurements (graphs measuring time in  seconds, lower is better; graphs using unit/s, higher is better).

This was before the release of GCC 4.6.x as well; LLVM has seen some incremental speed increases since those tests were run, but GCC 4.6.x was known to have major speed increases in its produced binaries over older versions. Especially on newer Intel platforms as that was a point of focused development by the GCC team, since Intel now dominates the desktop processor market. Apple exclusively uses Intel chipsets and with AMD recently announcing that they'll no longer be developing future desktop processors, Intel will maintain its position until another manufacturer comes along.

Don't get me wrong, I love the LLVM/Clang project and there will be a day when LLVM will supplant GCC as the king of compilers (for C bases languages), and I think it would be foolish not to be forward thinking and also implement support for LLVM/Clang, but for now GCC still produces superior binaries.

[reckless]

Still trying to fix a few bugs but based on xunxun's work i made the dragonegg plugins availiable for all languages but java.
Atm the 64 bit version works fine most of the time but the 32 bit version of the plugins causes linker errors (still investigating).

[reckless]

The linker error was a bug in dragonegg related to how mingw works and its fixed now by duncan sands. So dragonegg works on mingw now