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 03:09:32

> > I'm in the process of trying to remove the Boost dependency from my
> > project, as it is causing too many difficulties for non-developers
> > trying to run my code.  
> 
> This should just be a matter of providing the corresponding binary 
> dependencies along with the executable file when you make a release.
> 
> To decrease the binary dependencies you can link Boost statically rather 
> than dynamically.
> 
> (If you're talking about issues with compiling your code, then you 
> shouldn't be expecting non-developers to compile your code in the first 
> place.  That's what release zips/packages are for.)

That's ok for the Windows release (although it still causes me plenty
of headaches I'd rather not have to put up with), but unfortunately
it's not so simple under Linux.

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.

Then you still have the problem where every time the distro upgrades
Boost to a new version, all the existing binaries break and have to be
recompiled.

You're right in that a static build would address many of these issues,
and I must admit that hadn't occurred to me, but I am trying to
encourage people to contribute to the codebase so I do still want them
to be able to compile the source without wasting too much time figuring
out dependencies.

And of course I still have to deal with it all myself, and it's not
easy.  I use Travis CI for my testing, which among other things allows
me to make sure my code compiles on a Mac, a platform I don't otherwise
have access to.  But Travis has an old version of Boost preinstalled
that my code won't work with, and upgrading it gets me a version
compiled without C++11 support, so I can't link with it.  In order to
compile my code, I have to download Boost and compile that first, then
start compiling my own code.  But that takes so long Travis thinks the
build got stuck and terminates the job, causing a build failure.  I
actually went so far as to set up a GitHub repo[1] that through Travis,
would build a Homebrew package of Boost, and upload it as a GitHub
release, which I could then pull in before compiling my own code on
a Mac through Travis.

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!

Until C++11 it was worth the effort to get Boost installed, but having
things like shared_ptr and bind made part of C++11 was a huge step
forward.  Now I use hardly any native Boost code - aside from Test and
Program_Options - so it's at the point now where swapping these out for
alternatives is starting to look like the easier option.

Cheers,
Adam.

[1] https://github.com/Malvineous/travis-homebrew-bottle