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.
backward PP compatability. Add BOOST_category_item_AVAILABLE as a
defined, or not, symbol for use with "#ifdef" or "#ifndef". Add
documentation of macros used for detection and version information. Also
replace direct use of BVN(0,0,0) and BVN(0,0,1) with more meaningful
macros that are globally defined, and hence consistent.