Hacker News Reader

Comment by pjmlp | Hacker News Reader

If anything there are plenty of options.

How come we have managed during the last 40 years?

I should have said: the lack of standardized build system. CMake is a pain, Bazel, vcpkg, autotools, plain old Makefiles, etc... All of them do not match the developer experience of npm, cargo, etc...

Yeah we managed, I never said the opposite. I only talked about why I liked header-only libs: because I just copy/paste the source in my source tree, regardless of the build system I use.

If I'm using CMake, and a library is using autotools, I'll have to rewrite the lib's build system, and maintain it. I'm too lazy for that.

You should have installed it already via the OS package system, or the modern alternative, conan/vcpkg.

It was a massive pain in the butt in that time. Just try to intregrate a "standard library" like libjpeg or libpng into your cross-platform project. That's exactly why everybody has switched over to stb_image.h to quickly load image data without hassle.

Easy, have your "load/save_image" calls the OS provided APIs for image handling, while on UNIX assume the libjpeg-dev or libpng-dev are already installed via the OS package system, have the makefile targets adjusted as needed per platform.

Nowadays, use cmake + conan/vcpkg as alternative as well.

Do we need to spoon-feed everything?

...and with all this you just made everything a thousand times harder (and more brittle) than it needs to be. Integrating stb_image.h is literally just a single #include statement, no matter the platform, build system or dependency manager (if any).

Other than having someone keep track of it, across all projects it gets included, even if it gets vendored somewhere there is the issue with symbol duplication across binary libraries used across teams.

Also it is a toy library in size, then there are those that can be used to stress test compilers.

Reply on news.ycombinator.com