Re-introduce Clang host compiler support

[ptheywood]

• Add clang specific warning suppressions to FLAME GPU 2
• Add clang to CI
• Choose final clang CI additions
• Verify minimum supported clang (9?)
• Verify if swig built via clang works correctly or not, or what minimum version is required to do so
• Update vis repo with any required warnings / suppressions / fixes
  • Update vis hash post-vis merge
• Update readme
• build and run test suite

Closes #623

---

CUDA 11.8 lists Clang 14 as the supported version.

CUDA 11.0 lists Clang 9 as the supported version, however CMake reports that CUDA would not build somethign in this case on CI. Need to debug on a local 20.04 box (i.e. the office).

11.1 + clang 9 seems to be compatible (although a warning suppression flag is too new for this)

[ptheywood]

When CUDA dislikes the version of clang (or gcc) used, it emits a compile time error. When CMake attempts to check for a working CUDA compiler, it doesn't output why it failed, just that CUDA could not be found.

CUDA 11.0 requires clang < 10, with 9 listed in the linux installation documentation as the selected version (but > 3.2).

CUDA	Clang Requirements
11.0	< 10
11.1	< 11
11.2	< 12
11.3	< 12
11.4	< 13
11.5	< 13
11.6	< 14
11.7	< 14
11.8	< 15?

This is a bit noisy for our readme, so probably just saying "clang > 9 supported by your NVCC installation", which will also avoid us from having to maintain a list.

Clang 9 with CUDA 11.0 is currently failing to compile on my office machine (and presumably the same issue as on CI) due to what looks to be a stdlib mismatch, i.e. as its' linking aginast the gcc stdlib (which is fine) but it is linking against the most recent installed version, which in some combinations is incompatible. I.e. When using clang 9, there will be a maximum compatible libstdc++ version, of which the most recent version is too new. Uninstalling newer libstdc++ versions would be an overly dramatic fix with possibly bad consequences.
This is ultimately down to how ubuntu/debian have packaged things. A grim but less drastic option is to symlink the installations into unique directories that can be specificed by the --gcc-toolchain clang flag, but that's grim (and not 100% sure how to get that into CMake via env vars.

To verify if CI is doing the same or not, i'll need to add some extra ci stuff to output the relevant file.

[ptheywood]

Updated list of supported clang's per CUDA based on the linux release notes. Pre CUDA 12.2 a single value was listed, which may have been the upper bound, although it differs from my previous table a little.
C++20 in 12.x would change the lowest supported clang.

Recent installation guides also state that:

We only support libstdc++ (GCC’s implementation) for all the supported host compilers for the platforms listed above.

<filestystem> in clang required -lc++fs pre clang-9, so clang 9 should be our minimum, though CI is suggesting there are errors in some of the above combos.

cuda	clang
12.3	7.x - 16.0
12.2	7.x - 15.0
12.1	15
12.0	14
11.8	14
11.7	13
11.6	12
11.5	12
11.4	11
11.3	11
11.2	9
11.1	9
11.0	9

[ptheywood]

Some clang CI builds now in a good state, others not so much for a mix of reasons:

• stdlib errors probably from differences between the gcc stdlib not matching clang's headers expecteations, though cuda only supports clang using the gcc stdlib.
• Some <filesystem> issues for some clang/cuda versions
• errors mid pyflamegpu compilation. Memory maybe?

Some of these could also be that although i've matched supported major clang version to the cuda version, a minor clang update has caused an incompatibilty.

Recent clang + recent cuda (14 and 12+) seem to behave nicely though.

[ptheywood]

CUDA 12+ with clang 11-14 (all that's easily installable on ubuntu 22.04) are all happy enough on CI now for vis and non vis builds.

CUDA 11.x is unhappy for a number of reasons, mostly internal compiler issues often reported elsewhere.

Rather than put extra effort into adding support for as broad a clang version as possible, going to instead state that clang is partially uspported, but only tested for cuda 12+ and add 2 ci jobs, cuda 12.0 clang 11 and cuda 12.x clang 14.

CUDA 11.6 + clang 12 and CUDA 11.2 + clang-9 work for console builds, but not vis builds. Other combinations tried from 11.0 + clang 9 to 11.8 + clang 13 using the cuda supported clang's don't work on ubuntu 20.04/22.04. They may work on other systems with different gcc stdlib's installed, but not going to support that.

[ptheywood]

clang 7 does not build, with nvcc reporting it does not understand c++17 (although clang itself claims 5+ does).

Clang 8 and clang 9 without vis build on ci ok with cuda 12.0. Vis builds encounter errors during pyflamegpu building

make[3]: *** No rule to make target '/libSDL2.so', needed by 'swig/python/CMakeFiles/pyflamegpu_swig.dir/cmake_device_link.o'.  Stop.

This is although libsdl2-dev is installed and found by CMake.
I've reproduced this on mav which is running ubuntu 20.04 still. assume it's an issue in ubuntu 20.04's libsdl2 build with clang?

The 20.04 SDL2 Cmake file installed at /usr/lib/x86_64-linux-gnu/cmake/SDL2/sdl2-config.cmake contains

# sdl2 cmake project-config input for ./configure scripts

set(prefix "/usr") 
set(exec_prefix "${prefix}")
set(libdir "${prefix}/lib/x86_64-linux-gnu")
set(SDL2_PREFIX "/usr")
set(SDL2_EXEC_PREFIX "/usr")
set(SDL2_INCLUDE_DIRS "${prefix}/include/SDL2")
set(SDL2_LIBRARIES " -lSDL2")
string(STRIP "${SDL2_LIBRARIES}" SDL2_LIBRARIES)

While 22.04's version has a significanlty more complex sdl2 config file.

---

Edit - this might actually be an issue in our custom sdl2 handling in the vis branch for older libsdl2, which creates the imported target using SDL2_LIBDIR, but this does not appear to be set in this case, although this behaves as intended when using GCC?