Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
Clang based CC, new CC interface
Alpha:
--- Quote from: dmoore on January 29, 2014, 04:33:40 pm ---* Which docstring formats are you able to highlight code for? (What tool are you using to do the highlighting?)
--- End quote ---
Maybe it would have been better to try to use a hidden Scintilla control, but to simplify things, I wrote a pseudo-lexer.
--- Quote from: dmoore on January 29, 2014, 10:12:42 pm ---
--- Quote from: oBFusCATed on January 29, 2014, 09:52:51 pm ---The last image is interesting. Can you try to explain how it works and what kind of API do you use?
--- End quote ---
Looks like just an editor hook, then uses wxScintilla annotations:
See, esp. DiagnoseEd, in https://github.com/alpha0010/ClangLib/commit/6a0c09cf1cd39448d6fa6d022afd9f3a0bed6ebb#diff-2c47c86d730d3c95d68ec3fa39ad7e7bR719
--- End quote ---
Yes, that is it.
--- Quote from: oBFusCATed on January 30, 2014, 12:16:16 am ---100% should be part of the SDK...
--- End quote ---
Hmm... I will see if I can figure out a good way to do that.
--- Quote from: oBFusCATed on January 30, 2014, 12:16:16 am ---Does clang provide both CC info + errors/warnings info with a single compile/parse?
--- End quote ---
Essentially yes. Also, when working on the root source file of a translation unit (the .cpp), each update after the first parse is significantly faster because headers included at the top have their processed version cached.
With reference to performance, while working in a single editor, this plugin works well. However, the initialization of each new editor (a source file, not a header) can take 2-5 seconds under Linux, and upwards of 20-30 seconds with Windows (at some point, I will switch this to run in a background thread). Also, because libclang is organized by translation units, each of these takes 50-150 MB memory. (Of note, in this plugin, some of the files include Code::Blocks' PCH, and some do not. The files that do not use it are nearly instantaneous to initialize.)
From my testing, Clang's comment parser seems to have some issues under Linux, and on Windows, often completely fails to return anything (although, that might be error on my part, I am not sure).
--- Quote from: dmoore on January 29, 2014, 04:33:40 pm ---(btw, you can also use the README.md or README.rst to embed screen shots on the github page using a dir in your repo to place the images. Nice feature of github IMO)
--- End quote ---
Thanks, I will look into that.
thomas:
So, although I should have known better, I wasted the day trying to get Clang-SVN under Windows working. Turned out it is the typical Unix-like open source shit that you expect. Why does everything that you get for free suck so much?
Install prerequisites, configure, and make. Yeah right. Python is a prerequisite for running the test suite. Of course you don't want to run the test suite, but make will fail with "python version > 2.5 required" if you don't have Python installed. So you install Python version 3.3, and guess what, now make fails with "invalid syntax".
Searching the web for the exact error gives a solution: "Yeah, print is a function in python 3.x now, you will need the latest 2.x version".
Great. Fuck you.
Using vanilla MinGW or MinGW-TDM, configure works fine, but the build fails after 3-4 seconds because off_t is not defined (which is, of course, total bollocks).
So you install Python 2.7 and a MinGW-w64 based compiler, and behold, it configures and builds.
In fact, it builds every darn architecture that LLVM supports, which only takes like 2 hours. So you reconfigure with --enable-targets. No matter what you choose, you get a "cannot determine triplet" error. Fuck you, again.
So you reconfigure again, and rebuild all that shit. The build process has no way of running without the test suite. Anything but "all" fails, and "all" runs the test suite. Further, make hangs when you call it with -j, great. Single-threaded builds in 2014. Fuck you, again.
Surprisingly, it indeed -- finally -- generates a working 460MB compiler. Except there are no C++ or C++11 headers.
So you reconfigure for C++11 support (which you have to specify explicitly!), and guess what. It fails because i386 is not supported under 10.4 and under OSX. The fuck, what?
I'm building a Windows compiler under Windows, using a Windows compiler, targetting Windows. What do I care if i386 is supported under OSX?
EDIT:
Interesting. Looking at the SVN log, I find an entry from earlier today "Try to unbreak MinGW build". So apparently this is a known problem. Well, I'll give it another try next weekend.
killerbot:
I feel your pain Thomas, I have suffered these things too.
And what is really frustrating these clang guys go shouting all over the world how nice their compiler is a, how much better the gcc and so on. Maybe that is true, but actually as long as they don't make it usable, the only thing they have created is a big piece of shit. I really hope that one day some guy over there really uses his brain instead of their self proclaimed "oh so good compiler" story.
But in the meantime they ship OS-X with even super old gcc, avoiding people to use gcc on their lovely overpriced mac books.
oBFusCATed:
Thomas:
1. Have you reported this problems to clang devs, no point shouting here:)
2. Have you tried the binaries, I think they build them everyday
Killerbot:
You can use newer gcc using macports as far as I know, but they are not 100% compatible :)
Ceniza:
Just for the record.
The reason why Apple stopped shipping and using newer versions of GCC is because of their current license (GPL3), same reason why they had to drop samba and roll out their own substitute.
As for LLVM and Clang, their main platform is OS X (more like BSD in general, since FreeBSD also decided to drop GCC and move to Clang/LLVM). Linux, being related to Unix and BSD, can, of course, more easily get Clang/LLVM working. Windows, as usual, is the outsider (however popular) when it comes to standards (what Microsoft managed to implement of POSIX is, at its best, laughable).
What I find kind of ironic is the eagerness to bash on Clang/LLVM for its poor support for Windows, when Code::Blocks itself (and wxWidgets for that matter) is in a rather sorry state when it comes to OS X support. The interesting thing is that both projects share the same reason for it: lack of community support and contributions for a specific platform.
By the way, I thought Eranif managed to get Clang working for his code-completion in CodeLite years ago, or am I getting confused? If so, he may be the best guy to ask about it.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version