<div dir="ltr">The only usage of CMAKE_C(XX)_COMPILER_ID is for -fcolor-diagnostics.  Why not use the feature testing macro add_flag_if_supported() used elsewhere in the file?  I actually don't like those kinds of compiler tests because they make configuration slow, but that's the dominant style for all the other flag checking.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 13, 2013 at 4:42 PM, Arnaud A. de Grandmaison <span dir="ltr"><<a href="mailto:arnaud.adegm@gmail.com" target="_blank">arnaud.adegm@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">From time to time, it happens that cmake picks up inconsistent C and C++<br>
compilers, especially for new comers or people not (yet) familiar with their<br>
development environment.<br>
<br>
This patch checks that both C and C++ compilers have the same ID (in cmake<br>
parlance) : Gnu, clang, ... This would catch gross mistakes at an early stage<br>
(configuration) instead of failing way later during compilation.<br>
<br>
I am wondering though if we have some environment where such a mismatch is<br>
expected. Any thoughts ?<br>
<br>
Cheers,<br>
<span class="HOEnZb"><font color="#888888">--<br>
Arnaud A. de Grandmaison</font></span><br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div>