Boost logo

Boost :

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2020-06-29 08:46:32


On 2020-06-29 04:49, René Ferdinand Rivera Morell via Boost wrote:
> On Sun, Jun 28, 2020 at 8:26 PM Glen Fernandes via Boost <
> boost_at_[hidden]> wrote:
>
>> The concrete items mentioned that have been known to inhibit
>> participation appear to be:
>> - Mailing lists
>> - Boost.Build
>>
>> Not sure what to do about the second.
>>
>
> It's easy.. Make it abundantly clear that a build system, *any* build
> system, is expected or required for review. And one way to do that is to
> *require* no build system for review. Because if your library can be
> reviewed easily without a build system it means the portability of your
> code is good. Anything else should be a red flag for reviewers.
>
>
> PS. I'll keep living the dream when we don't distribute any build system
> with our libraries. Or the alternate dream where we distribute with 5 or
> more alternate build system specifications.

Assuming the library requires separate compilation, a build system is
needed for the library to be usable. Reviewing and accepting a library
that is not usable makes no sense.

Furthermore, in order for users to be able to use Boost, they need a way
to build it, that is compile and install artifacts of every library in a
common place. There needs to be a common interface for doing this.
Currently, this is achieved by Boost.Build, so any new library has to
integrate with it. If it uses a different build system internally, it
must at least support being invoked from Boost.Build. Without this user
experience will be severely hampered.

I'm not insisting that Boost.Build should be that common user interface
for building Boost, but there must be one. I'm not attached to
Boost.Build specifically - any build system that is able to handle
building and testing Boost, including docs, would do. However,
personally I'm opposed to having mode than one build systems per
library, as that unnecessarily increases maintenance burden.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk