4 ms·
> However, don't add to the pile of dependency hell that is already plaguing many open source projects If you create small libraries that don't produce shared
by pengaru 6y ago
> However, don't add to the pile of dependency hell that is already plaguing many open source projects
If you create small libraries that don't produce shared objects intended to stand on their own with a stable API/ABI, but are simply headers or at most produce a .a from source fully intended to become vendored in-tree, you're not contributing to "dependency hell".
- rossmohax 6y agoIn theory this vendored library might show up multiple times in a dependency tree and be incompatible with each other.
- pengaru 6y agoIt's hardly a "dependency hell" when it only affects developers, in what are essentially unique collision type situations, and are generally addressable by the developer because the source is all present. And upstream maintainers of such intended-to-be-vendored code should generally be receptive to improving compatibility and build system configurability for such situations. And if they're not receptive/it's abandonware, congratulations your vendored library is now a fork and fix it yourself. When we refer to "dependency hell", AIUI, it's in reference to unresolvable runtime dependencies creating hell for end-users.