Boost logo

Boost :

Subject: Re: [boost] Proposal for moving Boost to CMake
From: Daniela Engert (dani_at_[hidden])
Date: 2017-06-19 16:20:07


Am 18.06.2017 um 21:05 schrieb Louis Dionne via Boost:

> Boost.Build only is a major pain for our users since they (1) most likely
> don't use it in house, (2) don't know it, (3) don't want to learn it, and
> (4) have to deal with it whether they like it or not. If you go into the
> wild, you'll find
> - people that don't use Boost because it's too hard to build or integrate
> into their build system
> - people that only use the header-only libraries because they don't have to
> build them and/or because the integration is as simple as changing a header
> path
> - people that build properly but are tired of maintaining their bridge
> between Boost.Build and their own system

And then there are people (e.g. the developers in our organization) who
- have no clue about building any boost library
- don't care if a given boost library is header-only or not
- deal with the build system no more than pressing one button in the ide
- handle dependencies to boost by nothing more but stating "1.64.0" at
one single place in the whole software project. Finding the Boost
headers and auto-linking the pre-built libs matching their compiler
version, mode and bitness is *not* their business - that's done by the
build system.

That's all these people need to know in their role as "users". It's my
duty to make all of this happen without any sort of pain for them. We
are talking about Windows, MSVC and MSBuild here and this is the
experience our developers are accustomed to for years now. I am totally
aware that the story might be different for Linux, MacOS, et. al. I have
no problem in servicing my colleagues this way as long as a Boost
version is tested and versioned as a integrated composition of libraries
which builds with Boost.Build as only prerequisite.

Just my 2ct from my pov.

Ciao
  Dani

-- 
PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5

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