Re: [Boost-users] [test] Is standalone use possible?

Subject: Re: [Boost-users] [test] Is standalone use possible?
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-10-02 05:49:56

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.