Peter Heywood

CUDA 11.3+ is fine with visual studio 2019, so its just 11.2 (and 11.1) which breaks for us. This would prevent us from producing 11.2 wheels. We can't drop 11.2...

Upstream has a PR in to fix this. The simplest way to incorporate this into the cmake logic would be to just make our minimum the next release post merge,...

CCCL 2.3.0 has been released on github: https://github.com/NVIDIA/cccl/releases/tag/v2.3.0 This should include the fixes we require, so making our min CCCL 2.3.0 and fetching newer if not found should be ok,...

The v2.3.0 tagged commit does not include the cmake fix or msvc fixes, although they were backported to the `branch/v2.3.x` branch. There's a v2.3.1 tagged commit which also does not...

CUDA 12.4 has been released, which includes CCCL 2.3.1 according to the release notes. Checking `/usr/local/cuda-12.4/lib64/cmake/cccl/cccl-config.cmake` this still does not contain the cmake fix we require (i.e. it lines up...

CCCL v2.3.2 has just been tagged / released, which does include the 2 fixes we need, so it should now be possible to switch to this / this shouldn't be...

Attempting to not use the `using namespace` directives in 3ab584b9300ae67958ac019c3b20a356a21765c9 appeared to cause failures, however after reverting the commit the same failures still occur suggesting it is unrealted to this...

I've managed to identify the CI test failures as being caused by an update to `libexpat`, see #249

Discussed during meeting, suppressing deprecations for Boost 1.74.0 agreed as a finely scoped way to suppress these internal boost deprecation notes without hiding future boost deprecations.

Discussed in meeting: + Older `cmake_minimum_required` versions are not intended, so switching to 3.16.3 or removing where possible + Switching to non-derpecated `find(python3)`