Subject: Re: [boost] CMake Announcement from Boost Steering Committee
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-07-19 06:57:25
On 19/07/2017 14:41, Robert Ramey wrote:
> One thing that always seems to get lost in this discussion is the
> distinction between library developers and library users. Library users
> need a simple way to import libraries. If one where to make (or if it
> already exists) most library users would be satisfied if all that had to
> do was something like FindBoostSerializaton or something like that.
> Since they are downloading binaries, they wouldn't care how boost was
> built etc.
That doesn't necessarily follow.
From that perspective, there's two kinds of Boost library users
(ignoring those who want to actually modify Boost code):
1. The kind that just downloads prebuilt binaries and wants to use them.
This group could be amply served by providing a pkgconfig file for
Linux and a props file for Windows+VS -- though since ultimately in both
cases it's mostly just specifying where the files were put (which could
be different for each user) this is probably more of a documentation
thing (providing a template where they fill in the actual path
themselves) than anything else. I suspect the Linux distribution
package maintainers probably already do this sort of thing; if you want
to use system-provided Boost then it Just Worksâ¢.
2. The kind that wants to build the libraries themselves.
There's many reasons for this; some want to use them on compilers or
environments for which prebuilt binaries are not available; some want to
tweak the settings for some particular library; some just want
confidence that they have the actual source for the binary. These
people mostly just want a simple command to build everything (or
whatever subset they require). For the most part, they don't care how
it happens or what tool is used, but the fewer external dependencies the
better (as fewer things to go wrong).
I've made some assumptions, of course, but I believe this is true.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk