On 2/10/2017 16:09, Adam Nielsen wrote:
For Linux, most people expect to get binary packages from their distro maintainer. For niche projects like mine, they aren't going to carry my software, so I would have to maintain up-to-date installs of a dozen or so different distros just to build the binary packages.
It's much easier for me to release a source tarball or a git repo, as most non-developers can manage ./configure && make install without too much difficulty. But it's a pain trying to figure out what distro someone is using and how they have named the Boost libraries, and whether they need to install some -dev variant as well, and so on.
It is possible to add some lines to your configure script to verify that a library -dev package is installed, which errors out with a reasonably clear error (which hopefully makes the users think to go install the package from their normal package manager). It's a one-liner for most libraries, but sadly it's not quite that simple for Boost since it doesn't provide pkg-config files out of the box. I'm sure there's probably still a way to do it though -- in particular if you assume that the Boost includes are in the system path then failing anything better you could just do a header-existence test (see AC_CHECK_HEADERS).
It's having to jump through hoops like that that are putting me off any dependencies, not just Boost. Header-only libraries are so much easier to deal with!
While that's understandable, having no dependencies means that (in most non-trivial work) you're duplicating things that already exist elsewhere, which can itself be a source of bugs and maintenance headaches (of course, dependencies can be maintenance headaches too). It's fairly common though, and one of the sources of NIH syndrome. Various solutions have been made for this sort of thing (source package managers and the like) but inevitably it just forms a collection of competing meta-dependencies.