[REQUEST] Add LLVM support

[imwints]

Due to missing implementations in llvm btop didn't support llvm based compilation for some time.
It's now more or less possible to compile btop, with some tricks, with llvm and clang. I myself got a few llvm/musl system and I'd like to use btop on them aswell without a dependecy on gcc.

Ad support for llvm base compilation in the makefile.

When llvm's <ranges> implementation is complete we should rollback some workarounds.

Notes:
We need to use libc++ because clang cannot compile libstdc++'s <ranges> because it relies on concept which are not yet ready in clang.
We need to enable libc++'s experimental features for <ranges> to work properly.
We need to edit some flags passed to the compiler which are not known by clang.

If this gets accepted I can open a PR.

[imwints]

I think you saw my previous PR which was a bit hasty. I've read your opinion on adding another build system to the mix. I'm pretty sure I've read in those comments that you want to wait for better <ranges> support by llvm and don't want to implement a ton of hacks to support llvm prematurely.

This is just for llvm support and I don't care a lot what build system is used, however as you saw in my other PR I used cmake to do prepare this. The build file is here for @jan-guenter and maybe you to have a look at. It doesn't check if a flag is supported but it adds flags based on the compiler in use with generator expressions. Neat feature. ;)

[aristocratos]

Yeah sure, go for it. 👍🏼

When llvm's implementation is complete we should rollback some workarounds.

I'm not sure I necessarily agree with this though, as far as I know only ranges::view is an issue right now, and it's very sparsely used in the code (isn't it just the Tools::ssplit() function?), so better to just replace those functions. As long as the replacement code is well written there shouldn't be any performance difference.

[imwints]

You're right, specifically it's just the rng::split function. The Libc++ Ranges Status page has info about the missing parts. I'll have a look at it over the next few months and then we can decide to roll back the changes or leave it as it is.

[imwints]

I've encountered two problems today on another machine:

• Currently I can't compile with LLVM's compiler-rt and llvm-libunwind. The program segfaults on exit. (I've seen similar things with neovim and llvm-libunwind.
• I can't statically link against glibc (I think glibc can't be compiled with LLVM at all).

I won't open a PR until I figured that out unless you want something like a work in progress PR.

[aristocratos]

@stwnt
There's no hurry really, probably gonna be a while before clang 15 is the default clang version in macos and the big linux distributions.
And by the time it is, fixes or workarounds for the issues you're experiencing have hopefully been found.