Well, at bare minimum project needs to support two compilers: msvc for windows and gcc for other platforms. As many know, every compiler has it’s own ways for interpreting input code, own quirks and own bugs, that sometimes are needed to be worked around. It only currently adds complexity to support as many as four compilers, namely:
msvc
gcc
clang
icc
Motives for dropping clang support? It generates slower code than gcc and isn’t that widely used.
Motives for dropping icc support? It’s commercial, costs a lot of money and is closed source.
EVERY common platform today has gcc port. It even supports microcontrollers. I don’t think that supporting clang will be of any benefit. On other hand, ICC isn’t something to worry about now.
How that dropping would occur? Currently README includes examples how to compile VCMI using clang and icc - let’s remove it and add a more general line telling about how to use different compiler than gcc with statement that if something fails you’re on your own.
Why I’m writing that? I took a peek to clang compilation issue on our bugtracker. First fix was easy: clang didn’t knew what function to call. Next issue emerged that was rather complicated: clang didn’t understood function’s arguments correctly - and this was complicated. I don’t think that fixing it is worth that amount of work, especially if it’s clang’s fault and works without warnings under gcc, present on systems of a lot wider audience than clang.
I think we should just make some “minimum requirements” for compilers. Clang may eventually get better, a new developer may want to use clang (f.e because it gives better error messages or anything) so I think “no clang” is not the best way.
I agree that msvc and gcc are enough for almost everybody. But we should let others care about compatibility with other compilers if they really want to (and it’s not too troublesome for us – I can’t imagine making VCMI compatible with compiler that, for example, does not support SFINAE).
By the way, I’d like to be able to use some C++0x features, especially auto keyword and lambdas. I think we should wait though since using them would drop support for gcc older than 4.5, and, among others, Debian does not have stable release with gcc 4.5+.
Clang is currently maturing, it will improve. Of course I’m not saying about “no clang” sign, just message “if you want clang to be supported - patches are welcome”.
If someone wants to write a patch - no problem. Support can be added at later time, too - just really, not now. Fixing clang now and maintaining compiler support would be an effort compared to improving AI and I think everybody agrees that AI is now more important
Dude, chill out.
What would removing support for these compile do to VCMI ? Nothing.
On the other hand, even if they cannot compile it, they have a different set of checks and warnings than gcc, and have actually found real bugs in the code. clang is also to become (one day) the main compiler for Apple and the BSD folks.
So, case closed.
I strongly disagree. For now it would be less hassle. Currently README is written in a way that can make people think they must work. Actually at least clang doesn’t compile and breaks on correctly written code.
Clang (for example) has some problems with template argument deduction, see stackoverflow.com/questions/3859 … base-class suggests that the standard does not require the compiler to deduce this argument but it’s not forbidden either.
