On 10/13/2016 5:45 PM, Gavin Lambert wrote:
On 14/10/2016 06:46, Edward Diener wrote:
Point taken. I am considering a stand-alone cxx_dual, but its reliance on Boost Config is a pretty big burden to overcome unless I incorporate much Boost Config logic in my own code, which I am not sanguine about doing. Boost Config is a magnificent achievement, without which cxx_dual does not exist. I acknowkledge that in the doc.
Perhaps it's another argument for truly-modular Boost, where you can download individual libraries rather than a monolithic release.
There are many other arguments for what you suggest, not just cxx-dual. But without a versioning infrastructure, where each library has not only its own versioning information but can check if it is compatible with the versioning information of all its dependencies, I doubt it will succeed. Just randomly assuming that because Boost libary X depends on Boost library Y and the end-user places some release of Boost library X somewhere and some release of Boost library Y in the same "somewhere" directory structure where library X can find it, does not mean that Boost library X will work with Boost library Y.
I never really have any issues with including Boost code in desktop build environments, but it becomes a harder sell when writing embedded or cross-compiled code. (I usually still do it anyway, typically to plug holes in the libc, but it requires more justification.)
I have actually worked as a consultant for companies in programming groups, working on desktop applications and libraries, where the use of Boost was not considered, even for just header-only libraries, because the monolithic nature of the Boost distribution was not acceptable to the company. Many of these companies would rather spend literally millions of dollars rolling their own solutions, for which Boost already provided libraries that worked much better than anything that they could do. This is just dumb but this is how many companies for which I have worked as a consultant actually think. I don't think that the solution for cxx_dual, that it should not be part of a Boost distribution to be considered usable, is any more or less true of any other Boost library. But like you say if there were a workable modular Boost-like distribution of libraries cxx_dual would benefit from it like lots of other Boost libraries also would. While I understand Peter's point I do not think that it should mitigate against the ease of use of dual libraries in cxx_dual if that is what anybody really wants to do. However from asking my question and receiving your answer and others I can see that the problem which I have solved for myself in cxx_dual is not a problem at all for the large majority of library developers who have answered my OP.