3 ms·

> I’m very comfortable with doing build system maintenance, so the header-only “feature” seems like a straight-up drawback to me, killing my productivity with

> I’m very comfortable with doing build system maintenance, so the header-only “feature” seems like a straight-up drawback to me, killing my productivity with longer compile times. on linux / macos it's fine, an apt-something away, but on windows anything else than header-only is a pain if you are providing a C++ library, because you may need : - static and dynamic builds - debug and release (changes the std:: ABI by default on windows) - with static (/MT) and dynamic (/MD) runtimes (for whatever reason you can't link /MT with /MD code) - x86 / amd64 (and more and more people are using windows on ARM increasing the demand for arm and aarch64). So you need at least 2 * 2 * 2 * 4 (ie 32) distinct builds of your library if you want to cover all cases, and that's ONLY for vs 2015 and 2017 - older and newer versions break binary compatibility ; likewise for mingw / msys which needs its own set of libraries due to using itanium name mangling.

klodolph 8y ago
The only reason why this is a problem is because some people are doing this the hard way, manually creating Visual Studio project files for all 32 (or more) configurations. This is wasteful. There are better ways to do this. You should probably be using tools that generate the Visual Studio projects for you. Some of these tools have been around for a long time, many of them are quite mature. You should be using GYP, CMake, Bazel, or something similar for building. These tools all work on Windows in addition to working on macOS and Linux. Hell, if these tools don’t work for you, then writing a Python script which spits out the Visual Studio projects is not out of the question either… I’ve done it, it’s not terrible! If you are choosing to make a library header-only just because it’s too hard to build otherwise, well, my request is that you spend a day learning a build system which is not Visual Studio, and see if next time you make a library, you don’t restructure the code just to avoid learning how build systems work.
- jcelerier 8y ago
  I mostly use CMake and even in perfect CMake projects it's still a pain to do (since you need all these build folders) - and most projects aren't "perfect" CMake projects, e.g. I'm using portaudio, SDL and their CMake scripts are fairly opinionated and need manual hacking to get required build configurations
  - klodolph 8y ago
    I don’t mind modifying the CMake files for my dependencies, or when I’m using Bazel, writing the Bazel build files from scratch. I understand that not everyone feels this way, and it depends on how much labor you can spare for wrangling builds, but I still feel that this is less extreme / preferable to going header-only when header-only is not required for some other reason. Yes, updating my Bazel build files for third-party dependencies creates extra toil when I upgrade versions. In my experience, this is a small amount of toil compared to the API changes a third-party will introduce (e.g. upgrading libfmt to 5.0 meant touching a hundred files), so I am willing to pay that price to get faster builds. Or I’d put it this way: - Most of my time is spent making changes, recompiling, and seeing the results. Small improvements here have a large positive impact on productivity, and header-only libraries make this worse. - A small amount of my time is spent managing the build system and writing build scripts. Tasks like writing my own Bazel build script for a third-party dependency are not done often, maybe only when porting to a new platform or updating to a new version, so even though I spend extra time here, it is not burdensome.
  - krapp 8y ago
    But once you get CMake to build a VS project with, say, SDL and Lua already linked then it's still much easier than doing it through VS itself every time. The problem is getting it to do that, though. I don't know why it can't be simpler but apparently it can't.
    - jcelerier 8y ago
      sure, but it's even more simple to just add a single path to the headers. How many CMake config files export targets for debug and release windows libs for instance ?

klodolph 8y ago

The only reason why this is a problem is because some people are doing this the hard way, manually creating Visual Studio project files for all 32 (or more) configurations. This is wasteful. There are better ways to do this. You should probably be using tools that generate the Visual Studio projects for you. Some of these tools have been around for a long time, many of them are quite mature. You should be using GYP, CMake, Bazel, or something similar for building. These tools all work on Windows in addition to working on macOS and Linux. Hell, if these tools don’t work for you, then writing a Python script which spits out the Visual Studio projects is not out of the question either… I’ve done it, it’s not terrible! If you are choosing to make a library header-only just because it’s too hard to build otherwise, well, my request is that you spend a day learning a build system which is not Visual Studio, and see if next time you make a library, you don’t restructure the code just to avoid learning how build systems work.

jcelerier 8y ago
I mostly use CMake and even in perfect CMake projects it's still a pain to do (since you need all these build folders) - and most projects aren't "perfect" CMake projects, e.g. I'm using portaudio, SDL and their CMake scripts are fairly opinionated and need manual hacking to get required build configurations
- klodolph 8y ago
  I don’t mind modifying the CMake files for my dependencies, or when I’m using Bazel, writing the Bazel build files from scratch. I understand that not everyone feels this way, and it depends on how much labor you can spare for wrangling builds, but I still feel that this is less extreme / preferable to going header-only when header-only is not required for some other reason. Yes, updating my Bazel build files for third-party dependencies creates extra toil when I upgrade versions. In my experience, this is a small amount of toil compared to the API changes a third-party will introduce (e.g. upgrading libfmt to 5.0 meant touching a hundred files), so I am willing to pay that price to get faster builds. Or I’d put it this way: - Most of my time is spent making changes, recompiling, and seeing the results. Small improvements here have a large positive impact on productivity, and header-only libraries make this worse. - A small amount of my time is spent managing the build system and writing build scripts. Tasks like writing my own Bazel build script for a third-party dependency are not done often, maybe only when porting to a new platform or updating to a new version, so even though I spend extra time here, it is not burdensome.
- krapp 8y ago
  But once you get CMake to build a VS project with, say, SDL and Lua already linked then it's still much easier than doing it through VS itself every time. The problem is getting it to do that, though. I don't know why it can't be simpler but apparently it can't.
  - jcelerier 8y ago
    sure, but it's even more simple to just add a single path to the headers. How many CMake config files export targets for debug and release windows libs for instance ?