The headers on a Boost release are only present at the root. This adds that to the include search path so that the checks can also work on that structure.
The headers on a Boost release are only present at the root. This adds that to the include search path so that the checks can also work on that structure.
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
Generates cmake target that other libraries can use to express
their dependency on this library and retrieve any configuration
information such as the include directory.
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.
