"clang version 3.8.0 (trunk 256945) (based on LLVM 3.8.0svn)" was giving
"38 38" was a result. Now duplicates for fmake are trimmed and only the first
version found is used for bmake using its :tW.
With hat: portmgr
In collaboration with: dim
Modify make describe to automatically prepend ${PORTSDIR} if the path for the
port is not absolute
Checked with poudriere, portmaster, portupgrade
PR: 203685
Exp-run by: antoine
Differential Revision: https://reviews.freebsd.org/D3866
- Loop over USES twice, once to define all *_ARGS variables and once to
include Uses/*.mk. This allows all Uses/*.mk to examine arguments given
to other USES entries.
- Always define *_ARGS (possibly empty) and replace commas with spaces.
Similar for _USES_POST.
Adjust all Uses/*.mk:
- defined(u_ARGS) becomes !empty(u_ARGS)
- Eliminate helper variables like _*_ARGS=${*_ARGS:C/,/ /g}
- Some Uses/*.mk used ":" as argument separator instead of ",", but no port
used this form
- Uses/cran.mk: remove unused variable VALID_ARGS and USES+=fortran which
has no effect
- Uses/twisted.mk: simplify handling of the case where neither "build" nor
"run" arguments have been specified
PR: 193931
Exp-run by: antoine
Approved by: portmgr (antoine)
installed but is not cc. On such platforms, clang is usually not default
for a reason and so using it for C++11 is unwise. Instead, fall back to
newer GCC. On i386 and amd64, clang works even if it isn't the default,
so continue using it there.
This fixes the build for Boost, among other software, on PowerPC.
Approved by: bapt
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.
