Nuklear: A single-header ANSI C GUI library

Dealing with pre-compiled libs in the Visual Studio ecosystem is more complicated that you make it sound like.

For a start there are 4 incompatible standard libraries (dll vs static, debug vs optimized) and that's already a big headache. Also to a mix, a bunch of Visual Studio versions with enough difference to make it frequent that one compiled for e.g. 2010 doesn't work with 2015 or vice-versa.

To me the nature of those small libraries (regardless of the number of source files) is that they are highly portable and designed to always be compiled from source code to prevent those issues.

You have answered to:

> I really do not understand why 'single header' is considered a good thing, but I see this more and more often on libraries. What is the reason all the code is put in the header file?

With:

> I have mostly seen it done by (young) people who come from web dev. They bring their bad habits together with them. And they usually don't get a very warm welcome for that. (...)

And now you ask why I've listed all these libraries to prove otherwise? This is what I'm disproving with this list of old, experienced, non web devs writing good libraries that are well received and reliable.

You can't make a sweeping statement about an entire paradigm of writing libraries and then claim you just happened to ignore all of the facts that contradicted it like existence of SQLite, STB and the entire gamedev industry. Your logic is on the level of saying that "most nuclear power plants go boom" and claiming you just don't care about any except Chernobyl personally.

Where are your examples of these bad libraries made by young web devs that are not well received? Between few examples I gave you should have at least 10 by now but instead you tell me that some people learn C because it's 'hardcore' and that new C programmers struggle with C linking (both of which are obvious facts to any C or C++ programmer).

And there's nothing special with single file libraries about avoiding building or lack of updates, people can (and do) dump entire source trees into their projects to avoid having to build a separate library and it works just as well most of the time. People also do things like ship prebuilt binaries (especially C ones, which have a very stable ABI even on Windows, unlike C++) with their C or C++ project which is just as bad from the update standpoint as embedded source is or it's even worse since it tasks anyone trying to replace these with finding out how to build that library (which between CMake, premake, Scons, even changing compiler defaults - which once bit me when building a project with GCC - and God knows what else might be quite an adventure compared to just dumping the source into the project itself and rebuilding that).

"no depencies" until you actually want to use it. Because then of course you'll have to link with some non-standard library that can actually paint pixels on the screen. That was precisely what confused me.

1) A new dependency to install on every build server and dev's machine unless you're a 'nix only shop (e.g. not in gamedev) and sometimes even then (yes, I've had to apt-get install make) - at the very least this is a boatload of new setup/install instructions, in practice this also involves coordinating with IT, and heaven help you if you let your less programmery coworkers build from source too.

2) Which version of make? I have detailed instructions at work about which make to use with which makefiles such that all the stars align and the OS vars and other gnu tools line up such that our upstream Makefiles work without modifications (well, usually.)

3) Given the complexity of 2, what I'm actually going to do is automatically invoke make from whatever build system we're using internally.

4) Now that I have two sets of build configuration, I have a continual maintenance burden as conflicting dependencies and incompatible build settings need to be resolved. Since I deal with C++ libs and tools, sneezing too hard will cause incompatible libs. In practice, the Makefile will hardcode CCFLAGs, sometimes CC itself, and things like building with/without RTTI will cause incompatible libs I can't link without more Makefile tweaks.

5) When I get sufficiently fed up with the state of affairs in point 4, I'll integrate the tool into our own build system such that we have a single unified build system again and I don't have to make the same change in 5 places (our codebase + a measly 4 dependencies in this example.)

At this point I'm no longer using make and wondering why I didn't just skip directly to step 5 in the first place. Make is simple - so simple it doesn't address my needs nor solve my problems.

On HN, could you please not conduct arguments like this in the flamewar style?

Making this about "young" people who come from "web dev" is flamebait, which predictably takes the discussion into inner circles of hell. That's just what we don't want on HN.

You've done this kind of thing more than once before. That's bad. If you'd (re-)read https://news.ycombinator.com/newsguidelines.html and take the spirit of this site to heart—intellectual curiosity and thoughtful conversation—we'd appreciate it.