I hope that whatever solutions we come up with to handle the too-many-dependencies problem don’t stifle people’s motivation to create and share new packages. It’s not a given that useful libraries are going to exist. Too much friction and people will just stop sharing code.
-
-
In practice the best way to share code in C is to put a library into a .h file that you can
#include. Like the stb libraries. That’s the least friction that works across platforms (including MSVC and weird embedded compilers like Green Hills, etc.) -
But putting all code in a header file is an unnatural workflow, so people don’t often bother. Also, discoverability and versioning issues and so forth. GitHub helps some, but not as much as a package manager.
- 5 more replies
New conversation -
-
-
They were dropped into fontconfig presumably because fontconfig didn't want to take a dependency on glib because taking a dependency has a cost.
-
What they’d ideally be is in a string-utils package on their own. Nobody is well served by everyone reinventing these routines. It even hurts binary size to do so.
- 1 more reply
New conversation -
-
-
While I'm ranting here, I wrote an idiomatic equivalent Rust program: use std::env; fn main() { for arg in env::args() { println!("{}", http://arg.to _lowercase()); } } and a release build is 1.7M vs 275k for the whole fontconfig library. WTF?
-
The default release profile isn’t as small as it could be (turn on lto, add -z), and the binary is not stripped.
- 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.