Fixing a build can be pretty torturous though. My main thought when I'm looking at using a library in C++ is "oh god I hope this isn't a pain to build"
It has nothing to do with the integration difficulties.
Many ++ devs, me included, come from the C background and the amount of obfuscation Boost adds to the code is simply not worth any benefits it brings along. Yes, you can do a lot with a single line of Boost'ed code, but when it maps onto pages of simpler code, you basically lose a lot of control over the code. It also bloats the binary, which again may not even register as a viable concern with some, but which does have several long-reaching complications.
That's fair. C devs are also a little more used to being tied to specific OS facilities such kqueue/select. For me boost shines as an ASIO implementation. When that becomes stdlib, I'm not sure I would be compelled to use it.
This is along the lines of the traditional abstraction level debates, rather than anything particularly wrong with boost. I think it gets singled out unfairly as being a particularly difficult 3rd party library.
Why do you think it's only "a day." Also, you are forever introducing a dependency in your build chain, codebase, and executable. EVERY 3rd party dependency should be audited as such (performance, security, usability, etc). Boost is no exception, but for the amount of things it comes with (often), and the strain on the compiler requirements it produces, it is typically included as a last resort.
I should mention, people who talk without much context are a curious bunch too.
Yes there is always a balance of concerns. Build management with 3rd party deps is not trivial but its part of the lifecycle. In my experience boost integration really is "a day" on windows (including stashing the .libs as their own repo and reproducing a fresh 'git clone' build), and 10 minutes on a platform that you can use the package manager to obtain it. You can always excise it from a project later if you dont abuse 'using' statements. FWIW, I only really use variant and ASIO.
If you were adding boost to a project just to do some weird spirit/preprocessor hacks, I'd be wary. But if you told me you were going to write yet another cross platform ASIO wrapper because you couldn't figure out how to compile boost I'd be even more concerned.
