On 22/07/17 11:47, Peter Dimov via Boost wrote:
Roger Leigh wrote:
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.
Why didn't you ask here for us to include dependency information into the release?
http://www.boost.org/doc/libs/master/tools/boostdep/doc/html/ can do all sorts of dependency reports and I'm actively maintaining it, I've recently even added a cmake-specific output as I needed that to generate the -config files.
This is a serious question, Roger. I'm not trolling you or something.
We obviously can't roll back time so this is water under the bridge, but I'm still interested in your answer. You can be as blunt or explicit as you like.
Terrible to say, but my memory is failing me, and I can't remember! I'm pretty sure I did look at it, but there was some reason why I didn't find it a match for FindBoost's needs at the time, but I can't recall the specifics. I ended up writing this; it's in a CMake script, so it's a bit verbose: https://gitlab.kitware.com/cmake/cmake/blob/master/Utilities/Scripts/BoostSc... One thing the script does to is special-case a number of situations where a header of one component is actually a separate component in its own right, mainly related to python, mpi and serialization. It's also special-cases the zlib/bzip2 autolink stuff so we don't use the windows-specific data on other platforms. These might have been part of the reason, but I'm not entirely certain. Again not remembering exactly, but the mappings we have in FindBoost right now are not exactly boost component interdependencies but shared/static library interdependencies only, based on the autolink data. That might also have been part of the reason. I'd expect that with Boost providing per-component configuration files, this could be greatly improved to cover every component irrespective of whether or not it provides a library (or libraries).
Similarly, the pkg-config one. I'm genuinely interested in how pkg-config support, if we have it, is supposed to handle multiple build variants having been installed.
I've already solved that for the cmake -config files, but I'm not sure I see a way for pkg-config to support it.
It's been a while since I looked at this, but my understanding is that it can't by design. You have one variant installed, with a matching set of pkg-config files which point to those libraries. If you need multiple variants, you need to install each variant into a separate prefix and then configure pkg-config (via an environment variable) to search the desired prefix. This is a case where Boost's policy of appending all of the toolset/configuration/threading model etc. to the library name is somewhat unique and, and generally incompatible with how the rest of the world works. In general, I've found it a hindrance to interoperability, and solving a problem which I didn't have in the first place. No one else does it, and there's likely a good reason for that! At most, I add a 'd' debug postfix on Windows, and that's it (this is handled by CMake as a standard behaviour). If I need multiple configurations, I build them separately and explicitly; I don't expect it of the build system itself. Regards, Roger