On Sat, Dec 9, 2017 at 1:56 PM, Stefan Seefeld
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