$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 17:05:13
On 2019-04-27 12:53 p.m., mike.dev_at_[hidden] wrote:
>> -----Original Message-----
>> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Stefan Seefeld via Boost
>> Sent: Saturday, April 27, 2019 6:35 PM
>>
>> [...]
>> How Boost
>> libraries are installed however concerns Boost developers, not Boost
>> users.
> Exactly the opposite: I as a user of boost need to decide if and how I
> compile and install boost (if there are multiple choices at all) and I,
> the user need to make sure, my build script finds the version of a
> library I intended it to find.
You are getting things mixed up here. What you as user need to know 
about a library is whether it is going to be ABI-compatible with the 
code you are building yourself. It is the job of Boost developers 
(including packagers) to make sure all the relevant information is 
provided as package meta-info for Boost binary packages, so you can 
identify the variant you need.
You may of course still prefer to build Boost yourself, and I'm the last 
person to want to prevent you from doing that. The problem I'm concerned 
with is that in all this discussion the distinction between Boost user 
and Boost developer becomes very blurry, and all the sudden we (Boost 
developers) are confronted with imperatives (such as choices of tools we 
use ourselves to develop Boost) that shouldn't have to concern anyone 
but us.
I have been working with many different development platforms involving 
big software ecosystems that wouldn't be possible without robust package 
management, i.e. where the ability to separate "developers" from "users" 
is an essential means to enable large-scale development.
Monolithic builds simply don't cut it as they don't scale.
Stefan
-- 
       ...ich hab' noch einen Koffer in Berlin...