On 2019-04-27 11:46 a.m., Mike via Boost wrote:
Coming at this from a different angle: It might make sense to reserve find_package(Boost_foo) for libraries that directly support installation from cmake. Not sure if such a split is a good idea, but I wanted to put it up for consideration.
I don't see the connection. How a library is packaged and installed is entirely orthogonal to how it can be found by downstream build systems. What Peter added is some support logic to let dependent packages find Boost libraries, which is great for users of Boost libraries. How Boost libraries are installed however concerns Boost developers, not Boost users. While I understand that some people would like to be able to build an entire software stack at once, I think this is a bad idea, at least in general. Package managers are a means to isolate the two sides, as it allows users to locate and access packages (including information of how to use them) without having to know anything about those packages were generated. The whole business of "find_package()" is infrastructure to support package management. So why would one destroy this encapsulation by tying package usage to package generation ? Stefan -- ...ich hab' noch einen Koffer in Berlin...