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