libcxathrow: Fix build on Musl

[meator]

I do not consider this change to be fully polished (but I left the code in a better state than it was in). I am open to discussion about the problematic of determining correct exception unwinding mechanism on different operating systems/libcs.

My intent is to package mesonlsp. To be honest, I expected a LSP for Meson to have a cleaner build process. This project depends on a lot of "throwaway forks" of popular libraries/projects with few custom commits added. As a package maintainer, I would prefer to see more robust solutions, and if they aren't feasible, I would like to see documented commitments to maintain these forks, to "backport" upstream updates and to release/tag versions every so often. The muon fork is especially discouraging. The current latest release is also not buildable (because it lacks 8edb5af).

But I understand that maintaining an open-source project is a difficult task (I have also noticed the call for maintainers). I intend my comments to be constructive criticism for areas which could be improved if the project wishes to spend its limited resources on improving the packaging experience.

To return to the focus of this PR, I would also like to note that the libunwind optional dependency should be documented somewhere. If I hadn't encountered issues with building mesonlsp on Musl which lead me to src/libcxathrow/meson.build, I wouldn't have noticed this dependency and I would have packaged a version of mesonlsp which wouldn't print any useful stacktraces on Musl. If there is interest, I am willing to collaborate on improving this documentation (but mesonlsp currently doesn't have a dedicated place to document the build or packaging process, it has only a brief shell snippet in README).

Checklist:

• Did you update the CHANGELOG?
• If you introduced dependencies: Did you update the mesonlsp.spec, scripts/create_license_file.sh and all GitHub Actions files?
• Did you run a profiler, if you inserted a lot of C++ code, especially in the Lexer, Parser or the Type Analyzer?

related to #174

[tristan957]

The primary author is a student in university as far as I know, so they have to take time away from open source activities parts of the year to focus on studies. In the meantime, muon also has a language server now, so it might be easier to package. I have no horse in the race related to which one is or will be better. I am just shedding light on the current situation.

[ognevny]

related to #174

msys2 is not actually musl, but thanks. will try later

[meator]

msys2 is not actually musl

I'm not saying it is. I'm only claiming that both build failures (Musl and MSYS2) are caused by src/libcxathrow/meson.build picking a wrong stacktrace handler. This PR fixes Musl support, I do not expect it to fix MSYS2 (but it shouldn't be that hard to modify this PR to fix MSYS2 too).

[JCWasmx86]

Ok, great there is another lsp for meson, so this repo will be archived

[meator]

muon also has a language server now

Are you talking about muon analyze? It is an useful analyzer, but it isn't fully compatible with Meson (all the project I have tried it on have failed the analyze call, because the projects use features not present in Meson) and it is not a LSP (there is a -l flag for this, but it does not communicate using LSP protocol).

[tristan957]

mesonbuild/vscode-meson#278