This gives 2 new variables to the porters:
ALT_COMPILER_TYPE which can be empty, clang or cc depending on what ${CC} is
ALT_COMPILER_VERSION which will give the porter a 2 digit version of the alternative compiler
Requested by: many
The compiler.mk comments and code state that COMPILER_TYPE can only be
of the value "clang" or "gcc". However, the code that determines this
allows for a possible undefined third state (empty string). BMake
will emit a lot of errors about badly formatted conditionals if
COMPILER_TYPE is empty.
Since, by definition, if the COMPILER_TYPE is not clang, it must be
gcc, so skip the conditional gcc check and just set it. The entire
file must be updated if support for additional compilers is desired.
This bug was discovered because the gcc detection code failed to
identify the DragonFly base compiler (GCC 4.7.3) as gcc.
Approved by: portmgr (bapt)
Supported arguments are:
- c++11-lang: the port needs a c++11 aware compiler what ever standard
library it uses, implies features
- c++11-lib: the port needs a c++11 standard library, implies features
- c11: the ports needs a c11 aware compiler implies features
- features: this will create a COMPILER_FEATURES variable which contains
the list of features ${CC} do support, implies env.
- env: the COMPILER_TYPE will be set to either gcc or clang.
By default the uses will try to use clang33 from ports when nothing in
base is relevant except if the user explicitly defines
FAVORITE_COMPILER=gcc in his make.conf
Please note that testing tinderbox prior to version: 4.0.1_1 is not able to
properly figure out the dependencies implied by this USES.
