CMake, modular Boost, and other stories

Mike

27 Apr 2019 27 Apr '19

3:46 p.m.

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. Best Mike

Show replies by date

Stefan Seefeld

27 Apr 27 Apr

4:34 p.m.

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...

mike.dev＠gmx.de

4:53 p.m.

...

-----Original Message----- From: Boost 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. And it *may* (I emphasize the may) make sense to give the user the ability to distinguish between libraries that have been built and installed via b2 (most likely starting from a regular boost distribution) and libraries that have been downloaded standalone from github and compiled/installed via cmake. Best Mike

Stefan Seefeld

5:05 p.m.

On 2019-04-27 12:53 p.m., mike.dev@gmx.de wrote:

...

...
-----Original Message----- From: Boost 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...

2024

Age (days ago)

2024

Last active (days ago)

List overview

Download

3 comments

3 participants

participants (3)

Mike
mike.dev＠gmx.de
Stefan Seefeld