5 ms·

Because apparently archived files are just too much for Windows devs?

flohofwoe 11y ago
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.
- Avshalom 11y ago
  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.
  - IshKebab 11y ago
    Tarballs don't really solve the problem as nicely as a single header file.
    - mcguire 11y ago
      "Nicely"? 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"
      - deleted 11y ago
        [deleted]
      - SolarNet 11y ago
        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.
- richard_todd 11y ago
  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.
  - to3m 11y ago
    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.
    - richard_todd 11y ago
      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!
      - to3m 11y ago
        We definitely are not :)
  - flohofwoe 11y ago
    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.

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.

Avshalom 11y ago
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.
- IshKebab 11y ago
  Tarballs don't really solve the problem as nicely as a single header file.
  - mcguire 11y ago
    "Nicely"? 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"
    - deleted 11y ago
      [deleted]
    - SolarNet 11y ago
      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.
richard_todd 11y ago
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.
- to3m 11y ago
  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.
  - richard_todd 11y ago
    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!
    - to3m 11y ago
      We definitely are not :)
- flohofwoe 11y ago
  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.