Jan

> Zig somehow auto-detects `libstdc++` via cmake. I believe it does this in `build.zig` https://github.com/ziglang/zig/blob/d0c06ca7127110a8afeb0ef524a197049892db21/build.zig#L715 (There are also other non linux parts that directly link libstdc++) Solutions include: - ~~abandoning...

this commit changed `GIT_OID_RAWSZ` to `GIT_OID_SHA1_SIZE` https://github.com/libgit2/libgit2/commit/dbc4ac1c76827e954e0aa27afe8bb7e0b8993a93 the earliest tag with it included is [v1.6.1](https://github.com/libgit2/libgit2/releases/tag/v1.6.1) According to the debian tracker it only has 1.5.1 in stable, ouch.

No worries, this happens to all of us.

upon reflecting, this isn't the proper solution but just an attempt at fixing symptoms caused by another bug.

I see those reasons and agree that it would be useful to be more strict but not as a default, the way cmake config headers are parsed is established by...

This PR came from a PR I made to Pragtical which was merged as is. Change it if you want, I don't care and its open to be edited by...

coming back to this I don't think 1 is a good fit because if the parent changes its name it would never be inherited 2 sounds good tho

> Then the question is whether we want to mirror CMake's behavior, or enforce stricter rules and require values even for `#cmakedefine` lines. If we want to implement cmakedefine then...

You have installed Lite-XL from either the continous tag or from the CI Please install the correct 2.1.5 version https://github.com/lite-xl/lite-xl/releases/tag/v2.1.5

I have downloaded every Windows release on the [v2.1.5 tag](https://github.com/lite-xl/lite-xl/releases/tag/v2.1.5), please verify you actually downloaded the correct thing, and if so please provide a link to the build you claim...