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).
I'm using AX_BOOST_* (part of the "autoconf-archive" package on my system) which works quite well. It seems more reliable than the previous boost.m4 I was using, which itself wasn't too bad at all. In my experience identifying the missing libraries hasn't been too much of a problem, it's mostly been about how to figure out what needs to be installed on a given system. Boost hasn't been too bad here for the end users (it's mostly me struggling any time I want to compile outside my local machine) but some of the other dependencies have been much worse (any time I have to depend on an SVN version to get a critical bug fix.)
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.
Yes you're right, either way you have maintenance overhead. However from where I'm sitting now the grass looks a lot greener on the other side, and you know what that means... Ask me again in a couple of years whether it was worth it or not :) In some ways I see the industry in general moving towards this trend. Header-only libraries mean you can lock in a version that works with your code, and upgrades won't happen behind your back, forcing you to adjust your own code to make sure it works with the latest version. Docker is now quite popular, and follows the same philosophy - locking in versions and configurations of dependencies so that you don't need to keep reconfiguring things all the time as new library versions are release. Node.js and other scripting languages now favour locking in specific versions of their dependencies for the same reason. You still have to update your code when you grab new versions of the libraries, but you can choose to do that when you have the time to spend on it, you're not forced into it just as a deadline approaches. So I see going header-only for my C++ dependencies as perfectly fitting in with this trend! Cheers, Adam.