WIP: Add clang support

[rhubert]

Add support for clang and provide wrappers + to use it as a "drop-in" replacement for gcc.

The clang-class could be used to set CC and CXX to the clang wrappers so that the remaining recipe could stay untouched.
By adding clang to cpackage it becomes the default compiler, but since there are many autotools-based packages not compiling with clang I disabled clang within the autotools class. So only cmake and meson packages are using clang.
I haven't compiled all packages with clang so this might break some packages. But at least for the packages we're using it works this way. As an alternative it would be also possible to selectively enable clang for packages where it has been tested. 🤷

⚠️ devel::clang compile time is ~1h on my core ultra 5 using 10 cores...

There is one known issue I couldn't solve - it doesn't compile outside the sandbox:

[186/204] Linking CXX executable bin/llvm-min-tblgen
FAILED: bin/llvm-min-tblgen
[...]
x86_64-bob_compat-linux-gnu/bin/ld: /usr/lib/libzstd.so: unknown type [0x13] section `.relr.dyn'

I guess this is because the host-compat-gcc is too old to work on my (arch-based) system...

[rhubert]

Depends on #232 ...

[jkloetzke]

Thanks a lot! 🎉 I'll have a look in the next days.

There is one known issue I couldn't solve - it doesn't compile outside the sandbox:

[186/204] Linking CXX executable bin/llvm-min-tblgen
FAILED: bin/llvm-min-tblgen
[...]
x86_64-bob_compat-linux-gnu/bin/ld: /usr/lib/libzstd.so: unknown type [0x13] section `.relr.dyn'

Looks like it is using the wrong library. The compat-toolchain is a cross-compiling toolchain! That should never use libraries from the host.

(BTW, the CI build failed because Bob was not updated on ci.bobbuildtool.dev. I've fixed that.)

[rhubert]

I added a small patch to work around the issue with the zstd lib. Looks like the cmake parameter is not passed to the native configuration when cross compiling and a shared zstd is the default...

[rhubert]

I'm still rebasing our ~4 years old basement to the upstream basement / basement-gnu-linux. Turns out building the latest mesa3d for intel requires llvm-libs + (ocaml) bindings as well. I'm in progress of reworking this...

[jkloetzke]

Thanks. That is very much appreciated!

I'm still pondering about how we should exactly integrate clang support. I think there are two use cases:

1. The user might want to compile selected packages with clang for whatever reason. This might be its own software packages that need clang or because certain clang features are needed. In the end, clang is just a replacement for gcc and the recipes should better not need to care.
2. A package actually requires clang for compilation. Not sure if such packages exist.

I would consider the need for LLVM to be somewhat independent of this. Clang is really the C/C++ compiler frontend for LLVM and serves as a drop-in replacement for gcc. Packages that need LLVM can still be compiled with gcc, they just need the tooling and/or the library. AFAICT rust bindgen is such an example too.

Then there is also lld as a replacement of the GNU linker. Not sure if there is a use case for this but given the speed advantage, some people might want to give it a try.

But because there certainly are packages that cannot be compiled with clang, I would not make this a global decision. Instead, a project may enable clang for parts of the dependency tree. How to enable clang without modifying existing recipes is still something where I have no good idea to be honest.

BTW, there seems to be Yocto layer and there they seem to have a rather large blacklist of incompatible packages. Additionally, the layer seems to modify many other recipes.

[rhubert]

ATM we only have use-case 1, but with some additional requirements. We're compiling our packages with both, gcc and clang to get different warnings or errors. We're also using different version to check if it breaks with an older version and so on. Obviously we don't want to edit the recipe to switch between clang and gcc. This is done in the clang-class either setting CC and CXX to clang or gcc.

We're not using lld or the libcxx and I'd leave this open for now. The mesa stuff seams to require llvm-libs, llvm-libclc, llvm-ocaml-bindings and all the dependencies. Unfortunately I don't have access to my changes before 2nd week of January due to some technical issues.

For me it would be also fine to upstream only the llvm-recipe (I think it should go to libs/llvm.yaml(?), and maybe also to basement-gnu-linux (??)) and a clang-support class. This way we would simply add clang to the packages we want to build with clang and no other upstream recipe would be touched.

[jkloetzke]

Having support for clang in basement totally makes sense. It's just a question how it is done exactly.

The BASEMENT_HAS_CLANG variable does not look right, though. It will cause all packages to be rebuilt even if USE_CLANG is not set. Intuitively, I thought something CPACKAGE_USE_CLANG could be used instead. If set, the clang tool is added to buildTools and the package is built with clang. But this still feels like it does not give enough control because it will apply for a whole dependency tree. Right now I don't have a better solution, though.

The recipe itself could be named recipes/devel/llvm.yaml. Clang would be something like devel::llvm-clang and libclc devel::llvm-libclc. I know the naming is suboptimal for packages that provide tools and libraries from the same source package so there is no good rule how to name such packages.