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

Subject: Re: [Boost-users] [test] Is standalone use possible?
From: Adam Nielsen (a.nielsen_at_[hidden])
Date: 2017-10-02 11:02:39

> 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.