If compile-time is a concern (it isn't in my experience, at least if the rest of the project is C++ code), you can still wrap the library-header into your own header and put include-guards around it :)
Did you ever try to link with externally compiled libraries on Windows? :)
It's an absolute mess, the lib files are incompatible between Visual Studio versions, whether threaded/non-threaded/DLL/static MSVC runtime is used, whether linktime-code-generation is used, if there's C++ code in it, a release lib cannot be linked against a debug executable, etc etc etc...
Only sane solution is to drop the sources directly into your project. Whether it's just a header or a header/source pair is just a small detail, admittedly.
Yeah but "externally compiled libraries are a pain so I'm going to put the entire source in a single header file because tarballs man, how do they work" is a hell of a non sequitur.
It needs to abuse the preprocessor to avoid having multiple conflicting copies of the functions.
The implementation mode requires to define the preprocessor macro
NK_IMPLEMENTATION in *one* .c/.cpp file before #includeing this file, e.g.:
#define NK_IMPLEMENTATION
#include "nuklear.h"
That's literally what the preprocessor is for. The C++ inline keyword basically has the same effect, and probably half (or more) of your headers "abuse" it for exactly this purpose.
Putting external library source files directly into my project does not sound sane at all, and it is definitely not the only option for static libs on Windows. You can also make the library project a component of your solution, and add a reference to it in dependent project(s). That way, they have proper separation but are all built from source.
Having now read the rationale for single header libraries, I am completely unconvinced. These people either don't know how their tools work, or are making bad choices to coddle people who don't. Even forgetting the wasted time parsing the #ifdef'ed out implementation section over and over, it screws up separate compilation. Every time you tweak the implementation section, all the files that #include it will recompile for no good reason.
I was convinced of the header-only approach when I replaced DevIL, libpng and libjpeg (all of them made of a myriad of source files and build options, not to mention using non-portable build systems that don't really work out of the box on Windows) with 3 stb headers: stb_image.h, stb_image_resize.h and stb_image_write.h
Even if the compile time is affected (which I never noticed) this is only a minor inconvenience compared to the wins those 3 header files provide.
It's not either "build-system dependent mess" or "everything in header." The alternative to "everything in header" is "header file has interface, .c file has implementation." Then you add the .c file to your project, include the .h file, and it works better than "everything in .h" since instead of 20,000 lines all other .c files in user projects have to see only a few hundred lines, which compiles faster. And that's how C projects were supposed to be organized since the beginnings. You don't have to have dynamically bound files if that isn't needed. Some licenses insist on dynamical linking, but when you make your library, your decisions on how it's linked are independent of your decision to stuff the implementation in .h.
I agree that libpng and friends are an abomination, but a reaction all the way back to a single header file is taking it too far. There is a healthier middle ground that doesn't go against the grain of decades of tooling. Wouldn't a streamlined interface and fewer build options be sufficient? It's not like compiling multiple source files is hard.
You're probably not going to be tweaking the implementation section.
I prefer the 2-file approach myself, but the basic idea of distributing source files that the user adds into their own project is a good one. I much prefer it to having a solutionful of random projects, each of which inevitably needs its settings carefully tweaking to make sure everything works properly. Though I do admit that is not a very high bar.
831 commits in this repository tells me it is tweaked regularly. I guess the next response is: you probably aren't going to be updating your copy. That, and the idea that a project full of random source files is better than a structured solution of component projects, tells me where people's heads are at. We're not going to agree on this!
https://github.com/nothings/stb/blob/master/docs/stb_howto.t...
If compile-time is a concern (it isn't in my experience, at least if the rest of the project is C++ code), you can still wrap the library-header into your own header and put include-guards around it :)
PS: also see here: https://github.com/nothings/stb#why-single-file-headers