libbuild2-autoconf VS llvm-project

> [...] treated some of the code used for various feature checks invalid and the end result was checks failing even though they should have passed - often with barely any notification to the user (the user would see a "no" instead of a "yes" in some check)

This is a perfect illustration of conceptual bankruptcy of the autoconf approach. Using compile/link tests and basing a decision on whether they succeeded or failed without distinguishing the reasons for failure will inevitably lead to silent false negatives.

If you are wondering what to and what are the alternatives, here is one approach: https://github.com/build2/libbuild2-autoconf

I forgot to say that I use this llvm build. Just download the release and point the clangd server to it.

Xtensa support (esp32). Will be interesting how this will be for Rust and Zig support for esp32

https://github.com/llvm/llvm-project/tree/main/llvm/lib/Targ...

https://www.phoronix.com/news/LLVM-Xtensa-Backend

https://github.com/espressif/llvm-project/issues/4#issuecomm...

https://github.com/ziglang/zig/issues/5467#issuecomment-1465...

Hopefully, in the future the installation will be simpler, as we are trying to upstream our LLVM changes (first 10 patches are already accepted!), and once we manage to upstream LLVM changes we will proceed with upstreaming our Rust fork changes.

The main discussion can be led back to this GitHub issue and this comment; fortunately, we don't need to build espressif's llvm fork anymore as they supply the clangd (this is the language server we need) and you can find the zip here. I'll briefly list down the steps required to set up vim with clangd to take advantage of clangd's features (auto-completion, linting, code refactoring ...)

In my case, it's pretty annoying that the Xtensa platform doesn't have official LLVM support. It's in progress but going very slowly.

The link to the espressive issue trackers: https://github.com/espressif/llvm-project/issues/4

Xtensa. They've got a fork of LLVM that supports it that they're working toward getting upstreamed. The community has a fork of rustc that uses it (and a quickstart crate) while we wait for it to get upstreamed.

https://github.com/espressif/llvm-project/issues/4 is a good example why updating llvm isn't easy and takes a lot of time.

Just to clarify - Gambit, Chicken, and Carp all compile to portable C.

I hadn't realized LLVM mainline doesn't support Xtensa. I'm surprised.

D does support Xtensa via LDC (https://forum.dlang.org/thread/[email protected]...). It looks like GDC also nearly supports it, requiring only a minor patch at present.

A functioning LLVM backend does exist (https://github.com/espressif/llvm-project/issues/4) and might be making very slow progress towards being merged. A quick search shows that it works for Rust. I suspect (but don't know) that it might work for Terra as well.

There's also the LLVM C backend (https://github.com/JuliaComputingOSS/llvm-cbe) but I've no idea how efficient such an approach is when applied to real world embedded tasks.