NOT_FOR_COMPILER/BROKEN_ON_COMPILER (was: PKG_SKIP/FAIL_REASON)

[Edgar Fuß <ef%math.uni-bonn.de@localhost>]

> After reviewing the uses of NOT_FOR_COMPILER, I'm inclined to say we
> should either leave it alone or rename the variable to
> BROKEN_ON_COMPILER, depending on how we feel about minor consistency;
> I don't think there's a measurable number of cases where it doesn't
> make sense to build a package with a particular compiler, only cases
> where it doesn't work. But also, the logic is used to pick a different
> compiler rather than to fail, so it won't make any difference to
> failure reporting and tracking.
Hm, wouldn't it make sense to distiguish between
a) This doesn't work wit gcc 2.9.21 because it has a bug in the optimizer that 
   breaks the code
b) This doesn't build with clang<1.2.3 because it relies on gcc extensions 
   that earlier versions of clang didn't support?
(with b), it might be clearer to invert the name, i.e. ONLY_FOR_COMPILER)

Perhaps it would also make sense to distinguish between
a) it (obviously) doesn't build (because it uses features the compiler 
   doesn't provide)
b) it (subtly) doesn't work (because the compiler is broken or the code makes
   illegal assumptions)