When a BSD sub-os header is included directly the general
OS_BSD predef is inidially defined as not-available. Which
warns as the sub-os header defines it. The fix is to unconditionally
un-def the OS_BSD predef.
fixes https://github.com/boostorg/predef/issues/111
boost/predef/other/endian.h has two ways of detecting the endianess:
(1) It includes <endian.h> if BOOST_LIB_C_GNU is defined, and then
use __BYTE_ORDER to decide the endianness.
(2) Otherwise, if (1) was not possible for some reason, it uses
architecture defines to decide the endianness.
(1) works perfectly fine with glibc toolchains, because
BOOST_LIB_C_GNU is defined, but it doesn't work with musl. Due to
this, <endian.h> is not included, __BYTE_ORDER is not defined, and
method (1) does not work, causing build failures on musl toolchains
that don't have explicit handling by architecture name (method 2).
So this commit fixes RISC-V musl build by adding support for the
__riscv architecture define, to determine that the endianness is
little endian.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This reworks the order in which the compiler predefs are checked to use
the ones that provide version info. Also add the arch predefs for older
compilers that don't define the predefs with version info for arm4,
arm5, arm6, and arm7.
Continuation of #94
Some releases of g++, on some platforms, whilst running under some
standards, may not define neither linux, nor __linux. Add detections
for __linux__ and __gnu_linux__ for robustness.
Currently BOOST_COMP_NVCC is never set but always BOOST_COMP_NVCC_EMULATED
because the NVCC preprocessor emulates the host compiler being used
(gcc/clang/msvc/...) which are detected earlier.
The nvcc compilation process is somewhat special as can be read here:
https://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/index.html#cuda-compilation-trajectory
The nvcc compiler precompiles the input two times. Once for the device code
being compiled by the cicc device compiler and once for the host code
compiled by the real host compiler. NVCC uses gcc/clang/msvc/...
depending on the host compiler being set on the command line.
Predef (as a preprocessor only lib) detects the one doing the preprocessing
as compiler and expects it to be the one doing the real compilation.
This is not true for NVCC which is only doing the preprocessing and which
is using another compiler for parts of its work. So for NVCC it should be
allowed to set BOOST_COMP_NVCC additionally to the already detected host
compiler because both is true: It is gcc/clang/... compiling the code, but it
is also NVCC doing th preprocessing and adding some other quirks you may
want to detect.
This behavior is similar to what boost config is doing in `select_compiler_config.hpp`.
There the NVCC detection is not handled as a real compiler (part of the
#if-#elif) but as additional option before the real compiler.
