On Sat, Dec 9, 2017 at 1:56 PM, Stefan Seefeld wrote:

Hi,

(Rene, there is a question for you at the end.)

On 09.12.2017 14:37, James E. King, III via Boost 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.

True.

Building Boost should be possible without any user setup. Except for the obvious need of a compiler. What do you mean by "complete"? 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.

If you are using and building a specific package you are almost certainly aware of what it's dependencies, both optional and not, are. After all you did read the library documentation that you are using, right? The one time you would not be aware is if you are just building stuff without an actual need. Perhaps for packaging to give to others. But then it really is your responsibility to account for dependencies as a package maintainer. For the benefit of your users.

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?

openmpi or mpich2 (mpi) python (python) libjpeg, libpng, zlib, libtiff (gil)

Would folks find it useful if this information was part of the standard "Building From Source" sections of the upper layers of documentation?

That would be useful indeed. Note however that not all of these dependencies are needed at build-time (some are header-only libraries, so the dependency needs to be met by the boost user, not necessarily the person who builds and packages boost.

Also, I'd be curious how this is dealt with by the conan packaging logic. I would expect it to be best to pull this kind of information from project-specific metadata, such as the meta/libraries.json file. Rene, can you comment on how this is done there ?

It's done manually. Any optional dependencies we are aware of have options to turn them on/off as wanted by the end user in the conan profile. We also created conan packages for as many of those external dependencies as possible. And where those can be built in all platforms reasonably we turn them on by default (you would need to explicitly turn them off in that case). For example IOStreams has these options for the external libraries < https://github.com/bincrafters/conan-Boost-Iostreams/blob/testing/1.65.1/conanfile.py#L15>. And it will automatically add a dependency if you use those libs, which is the default, to likely already compiled version of them < https://github.com/bincrafters/conan-Boost-Iostreams/blob/testing/1.65.1/con...

-- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

On Sat, Dec 9, 2017 at 1:37 PM, James E. King, III via Boost < boost@lists.boost.org> 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

On 09.12.2017 16:49, Tom Kent via Boost wrote: 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...