On 21/07/2017 16:25, Roger Leigh via Boost wrote:
Could I also point to this block in https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/FindBoost.cmake#L... . This is what we do in the absence of proper dependency information being provided by Boost, i.e. no pkg-config, cmake config or similar. We hard-code *every* *single* *dependency* from 1.33 up to 1.64 at the time of writing. I wrote a custom parser to extract this metadata from the autolink information in the headers, similarly to the above ticket. *We* pay the cost of this significant defect in the Boost project in the form of a high maintenance burden and breakage with every new Boost release. Most projects hardcode the information, but it's fragile and should be unnecessary, and so we took on that burden so that CMake users could use Boost without worrying about the problems. That's why this file is such a huge and over-complicated nightmare. As and when Boost provides proper configuration information, which I would hope the CMake conversion work would provide, we can throw this entire monster in the bin (most CMake Find modules are a couple dozen lines at most; this one is just shy of 2000).
Then this is a different problem from the build system. You hope the new build system will offer a better dependency information for packaging, but if Boost.Build experts are not too annoyed, I think we can get this much much faster than porting to CMake. People using different build systems than CMake could benefit from this, so we're improving the life of the 100% of Boost packagers. So while we are moving to CMake (if that happens because we find enough people to do the work), which can take several Boost releases, we could kindly ask Boost.Build experts to export that information in a compatible way with the most popular packaging systems.
[...]
I hope the above isn't too upsetting or controversial. I wanted to provide some perspective from the point of view of an outsider and end user, and potential contributor, about what things are like from the other side. Boost is a wonderful collection of libraries, but there are some key things which could be improved, and Boost.Build/b2 has I am sorry to say been one of the worst aspects of Boost. End users need to go through some pain to work around defects in Boost.Build, as well as Boost.Build doing things differently to most other build systems. Some might be due to my Boost.Build inexperience, but either way this is what non-experts experience. It makes using Boost unnecessarily painful and difficult.
I think this is a very valuable information. The SC has given a direction, I don't see fixing "annoying" Boost aspects goes against that direction. Best, Ion