$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] CMake, modular Boost, and other stories
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2019-04-27 16:34:46
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...