Re: [boost] Optional third-party libraries

Subject: Re: [boost] Optional third-party libraries
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-12-09 22:52:56

On 09.12.2017 16:49, Tom Kent via Boost wrote:
> On Sat, Dec 9, 2017 at 1:37 PM, James E. King, III via Boost <
> boost_at_[hidden]> wrote:
>
>> The boost documentation on the web site talks about building boost from
>> source, but I don't see information on how to leverage optional third party
>> libraries easily accessible in the documentation from the place the user
>> will most likely end up: "Building From Source".  This information seems to
>> be tucked away in documentation of various components, making it difficult
>> to actually build a complete boost.
>>
>> I think it would be a good idea to bring this information up to the top
>> level build instructions, at the very least itemize these third party
>> packages and then link to the relevant project-specific documentation pages
>> that talk about configuring to use them.
>>
>> Here are the third party optional libraries I know about so far and the
>> libraries that use them:
>>
>> bzip2 (iostreams)
>> iconv (locale - if icu not available)
>> icu (locale, regex)
>> lzma (iostreams)
>> openssl (asio, beast)
>> pthread-win32 (sync, thread)
>> zlib (beast, gil, iostreams)
>>
>> Any others?  Would folks find it useful if this information was part of the
>> standard "Building From Source" sections of the upper layers of
>> documentation?
>>
>> Thanks,
>>
>> Jim
>
> MPI needs an underlying C MPI library to build, but you have options of
> various ones you can link against. That makes it a bit different than the
> other things listed above, and that's why I've never included it with any
> of the windows builds.
The Fedora packaging logic includes variants for both of those (so you
can install separate boost-mpich and boost-openmpi packages, see
https://apps.fedoraproject.org/packages/boost).
I think it would be great if we could define packaging metadata that
make it easy to build individual boost packages along those lines, but
in a platform-agnostic way. That would not only benefit all the boost
maintainers for the various platforms, but also and in particular boost
users, who would see a platform-independent set of Boost components,
much like what Rene did for conan.

Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...