2015-05-14 13:10 GMT-03:00 Niall Douglas
Most avoid Boost.Build Again. Are they really avoiding it or this is just a result of starting outside of Boost and not being part of Boost yet. Getting into Boost will result in using Boost.Build to be part of the whole regression infrastructure. I’m pretty sure no library author would object to that.
Actually they do. They want to use cmake. Not Boost.Build. Again, the authors may chime in here to confirm.
Boost.Build is a pain. Boost QuickBook and DocBook are nice, but the tools are also a pain. I shouldn't have to download and maintain a Boost tree to make these tools work. It's like all or nothing. I'd like to see tools that are more modular, standalone and with no assumption that I'm building a Boost project. Of course, I'll migrate from CMake to Boost Build, as I want to see my ASIO-based HTTP library within Boost.
Everybody tries to use as little Boost as possible Are they really avoiding other Boost libraries because of some problem or don’t they just require other libraries? From the descriptions of the libraries that actually seems quit plausible.
Boost 1.x is obsolete.
It is obsolete because enough of Boost 1.x is now in the STL that you no longer need to use Boost 1.x.
[...]
Again, authors may wish to chime in or not themselves about their views on the matter.
In the case of Boost.Http, there are some Boost libraries that are not used because they have C++11 counterparts, like: - shared_ptr - cstdint - lambdas/bind/... - array - type traits - regex - ... Still, many Boost libs are used, like date_time, string algo, string_ref and a few others. I'd like to provide support for C++11 system error code too, but Boost's integration isn't so transparent yet. Actually, most of Boost.Http interface could be implemented in C++03 and the only trouble would be a migration path from C++03 enums to C++11 strongly typed enums. -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker