This has an enumeration of the various compilers that Cabal knows about. It also specifies the default compiler. Sadly you'll often see code that does case analysis on this compiler flavour enumeration like:

 case compilerFlavor comp of
   GHC -> GHC.getInstalledPackages verbosity packageDb progconf
   JHC -> JHC.getInstalledPackages verbosity packageDb progconf

Obviously it would be better to use the proper Compiler abstraction because that would keep all the compiler-specific code together. Unfortunately we cannot make this change yet without breaking the UserHooks api, which would break all custom Setup.hs files, so for the moment we just have to live with this deficiency. If you're interested, see ticket #50.

The default compiler flavour to pick when compiling stuff. This defaults to the compiler used to build the Cabal lib.

However if it's not a recognised compiler then it's Nothing and the user will have to specify which compiler they want.

Like classifyCompilerFlavor but compatible with the old ReadS parser.

It is compatible in the sense that it accepts only the same strings, eg GHC but not ghc. However other strings get mapped to OtherCompiler. The point of this is that we do not allow extra valid values that would upset older Cabal versions that had a stricter parser however we cope with new values more gracefully so that we'll be able to introduce new value in future without breaking things so much.