Tootfinder

If you're writing a library, you should really avoid #CMake. CMake is designed to lock you in. As in, once you release a #FreeSoftware project using CMake, you can't switch to another build system with causing real trouble to your users. And if you support multiple build systems, as soon as you start supporting CMake, some of your users are going to start locking everyone else in.
That's because CMake uses a custom package discovery mechanism that's hardly compatible with anything else, and that is so complex that it's very hard to reimplement it with any other build system. So when others start relying on the CMake config files being installed (and they naturally will, since that's how CMake does things), you can't stop installing them without actually breaking stuff. And if you want to preserve them without actually using CMake, well, good luck with that.
And if CMake is one of the options you support, then some of your consumers will accidentally start relying on it anyway. And this will be much worse for everyone, because now their projects won't work for people who build your project with any other build system. Which in turn will force more projects to use CMake anyway. Which in turn will make more people rely on CMake being used…
Use #Meson as the build system, it's clean and not designed to lock you in. Use pkg-config for library data; it's simple and portable.
#OpenSource

Kiedy jesteś tak przyzwyczajony do tego, że języki programowania mają "wysokopoziomowe" metody sprawdzania, czy ciąg znaków jest pusty, że próbujesz na oślep znaleźć coś w stylu `not x`, `x.empty()`, `len(x) == 0`… i dopiero po chwili zastanowienia dociera do ciebie, że to może być po prostu `x == ''`.
#Meson

When you're so used to programming languages with high-level methods of checking for empty strings, that you grasp for something like `not x`, `x.empty()`, `len(x) == 0`… and only after a while of thinking, you realize that it's `x == ''`.
#Meson

Some fun facts about #Python limited API / stable ABI.
1. #CPython supports "limited API". When you use it, you get extensions that are compatible with the specified CPython version and versions newer than that. To indicate this compatibility, such extensions use `.abi3.so` suffix (or equivalent) rather than the usual `.cpython-313-x86_64-linux-gnu.so` or alike.
2. The actual support is split between CPython itself and #PEP517 build systems. For example, if you use #setuptools and specify `py_limited_api=` argument to the extension, setuptools will pass appropriate C compiler flags and swap extension suffix. There's a similar support in #meson, and probably other build systems.
3. Except that CPython freethreading builds don't support stable ABI right now, so building with "limited API" triggers an explicit error from the headers. Setuptools have opted for building explicit about this: it emits an error if you try to use `py_limited_api` on a freethreading interpreter. Meson currently just gives the compile error. This implies that package authors need to actively special-case freethreading builds and enable "limited API" conditionally.
4. A some future versions of CPython will support "limited API" in freethreading builds. I haven't been following the discussions closely, but I suspect that it will only be possible when you target that version or newer. So I guess people will need to be building two stable ABI wheels for a time — one targeting older Python versions, and one targeting newer versions plus freethreading. On top of that, all these projects will need to update their "no 'limited API' on freethreading" conditions.
5. And then there's #PyPy. PyPy does not feature a stable ABI, but it allows you to build extensions using "limited API". So setuptools and meson just detect that there is no `.abi3.so` on PyPy, and use regular suffix for the extensions built with "limited API".