Pierre Kestener (9e6ba062) at 24 Nov 10:31
Just as a reminder: once this is accepted, there will be two small modifications in VTK:
Same as third-party/xdmf!3
Pierre Kestener (eb2daf75) at 17 Nov 04:50
Update BOOST_MPL_LIMIT_LIST_SIZE setup.
... and 2 more commits
Pierre Kestener (5c2ef074) at 17 Nov 04:32
Update BOOST_MPL_LIMIT_LIST_SIZE setup.
Ok, you're right; I'll update this.
Though, in principle BOOST_MPL_LIMIT_LIST_SIZE
is defined inside boost/variant.hpp that is included right after (line 49).
So if BOOST_MPL_LIMIT_LIST_SIZE is already defined, it means the user code already included boost/variant.hpp; it feels a bit wrong to override the value afterwards (after boost/variant.hpp already included).
If BOOST_MPL_LIMIT_LIST_SIZE
is already defined I suggest to put a #warning to inform the user.
try to address issue #33
I noticed uint64 is not supported as a data type.
Pierre Kestener (00c4f84d) at 06 Oct 13:07
Fix typo in comments.
Pierre Kestener (1322c697) at 06 Oct 13:06
add support for uint64 data type.
I'm sorry to bother you again, I recheck your commit, but it doesn't solve the problem:
Just change
file(REAL_PATH "${CUDAToolkit_TARGET_DIR}/../../" CUDAToolkit_MATH_INCLUDE_DIR)
cmake_path(APPEND CUDAToolkit_MATH_INCLUDE_DIR "math_libs/include")
into
file(REAL_PATH "${CUDAToolkit_TARGET_DIR}" CUDAToolkit_MATH_INCLUDE_DIR)
cmake_path(APPEND CUDAToolkit_MATH_INCLUDE_DIR "../../math_libs/include")
and it works for me.
it's nvhpc 22.7 on a RedHat 8 system. I agree with you this shouldn't occur but the sys admin team of our supercomputer made some symbolic links to some directories of nvhpc (probably for some reasons related to filesystem mounting but I'm not sure).
Looking at the way CUDAToolkit_MATH_INCLUDE_DIR
is built, I think that identifying the real path before appending ../..
would help in general; it should be harmless when no symbolic link is involved ?