Static linking is "easy" on any particular platform for a particular target. But build systems and IDE and all that junk make things more complicated. You might want to build the library with the same flags as your main app, for example. You might have several target architectures you need to build and link against (i386, x64, amd) x (debug, release, QA). Etc, etc.. It also makes it easier for the compiler to inline things.
Header only libs just make all these problems go away, and (IMO) there's not really any downside.
Well, the downside is that it's literally in one header file. Besides being gigantic, it's extremely annoying to search and parse by hand - this is an issue when that's also serving as the documentation. Especially in this case, it would be much nicer to have a "nuklear" folder with a bunch of separate (appropriately named) headers. The single `nulkear.h` header could just `#include` them as necessary.
I respectfully disagree. If they are separated into thoughtful modules, then it would be much easier to parse by simply looking at the file and folder names and going from there. This will especially be true when this expands past it's current state, and it becomes impossible (Or more impossible) to see what uses what.
IMO, 20,000 is already way to much, but when that reaches 100,000 even just editing it will be a chore, let alone using it. It will simply be unmaintainable and unusable. I say this having worked on code bases which have reached that point and attempted to deal with the issues it creates. There's a reason every decently sized code base out there uses multiple files and a hierarchy. It's a natural way to create modular code, and modular code is simply better code.
It depends on the editor, I think. It's criminal that so many editors still can't do what BRIEF did 20+ years ago, and give you a quick and easy way to surf through all C/C++ functions in the current translation unit. (e.g., http://i.imgur.com/dmlCCpH.png ).
That's why I still use a buggy BRIEF clone instead of a modern IDE. If I were forced to use someone else's idea of a code browser that was architected around files rather than subroutines, I'd probably be more inclined to agree with you.
The idea that the most appropriate way to organize source code happens to correspond to something that a (likely-long-dead) OS implementer chose to call a "file" is a notion that doesn't get challenged often enough.
Perhaps if you are the author of the 20,000 line header file, but from my experience, this is certainly not the case when developing software in a team. Having all the code in one file is significantly more difficult to understand for a new team member since it becomes more cumbersome trying to understand the dependencies between different modules.
On the same note, proper modularization of source files also encourages better discipline for dependencies among modules, such as discouraging circular dependencies.
