5 ms·
It's nice that they're being explicit about breaking changes, but it's still a pain that they're doing them in the first place. I understand the argument for mo
by eslaught 10y ago
It's nice that they're being explicit about breaking changes, but it's still a pain that they're doing them in the first place. I understand the argument for moving quickly, but projects that use LLVM suffer as a result.
Basically, any code that uses LLVM bitrots very quickly because the API is (potentially) incompatible on each release. The way that large projects (like Rust [0]) generally deal with this is by sticking close to the bleeding edge of development, and have an established process for integrating changes as they come. But smaller projects just don't have the resources to do this.
KLEE (a symbolic execution engine) appears to be 5 versions behind the newest release [1]. Terra (a language focusing on metaprogramming for high performance) [2] is only one version behind, but the maintainer has since graduated and I'm worried the community is too small to keep it from bitrotting.
Nominally the C API is supposed to solve this by being more stable, but it achieves this by exposing a smaller surface area, which means you can't do a lot of what you might need to do with this API.
I'd like a stable, full-featured API for LLVM. It sounds like they're going this way with the bitcode format, and I think they could start to move in this direction with the API as well. When the project was young, the argument was that avoiding stability allowed the developers the flexibility to explore design decisions and make different tradeoffs over time necessary for the long-term health of the code base. I understand that. But this instability makes it essentially impossible to maintain client projects without ongoing effort, and means that small projects almost always bitrot.
I think we know enough now to develop a pretty decent stable API for LLVM. And I'd be a lot more confident in trusting smaller projects that use LLVM if such an API existed.
[0]: https://www.rust-lang.org/ https://www.rust-lang.org/
[1]: https://klee.github.io/getting-started/ https://klee.github.io/getting-started/
[2]: http://terralang.org/ http://terralang.org/
- the_duke 10y agoThank you for the only comment that isn't shallow semver debate. And for being spot on. LLVM is an incredible piece of software, but it's the lowest part in the stack. Sure, clang, rust or swift have enough manpower to always follow, but smaller languages / compilers can't possibly hope to deal with breaking changes all the time. The constant breaking changes also make it very hard to support multiple LLVM versions simultaneously. Which makes development and deployment harder, because you can usually only install one LLVM version via distro packages. So if you want to compile something that depends on an older / newer LLVM version, you have to compile LLVM, which takes a loooong time and is not something you can bring many people to do.
- witty_username 10y agoLLVM has binary downloads (for Linux too); so there's no need for compilation.
- sanxiyn 10y ago> The constant breaking changes also make it very hard to support multiple LLVM versions simultaneously. Rust supports LLVM 3.7, 3.8, and 3.9, and it isn't particularly hard to do so. Very annoying, yes, hard, no. It does need a bit of manpower though.
- pyvpx 10y agoin open source man power is the hardest part, no?