On Wed, Jul 25, 2018 at 5:41 AM Mateusz Loskot via Boost < boost@lists.boost.org> wrote:
Boost - Dev mailing list wrote
The intention of this is to simplify managing a docker build environment for boost [...] This partially came out of the discussion we had a number of months back about how we handle third party dependencies. For the most part one has to look at README files in various locations to learn about them. This is an attempt to pull all the dependencies together for a complete build into one place (the Dockerfile).
James,
TBH, to me, this gives quite a little idea what is the actual purpose and target audience of the docker images.
Is it for Boost users, to provide them with Boost itself? Is it for Boost contributors, to provide them with development and testing environment? What do you mean by "all the dependencies", Boost itself or deps required by Boost?
Best regards, Mateusz Loskot
It allows for easier boost development and release engineering by providing docker images that are capable of building, testing, and packaging boost on a variety of platforms. Right now two flavors of Debian and Ubuntu each are provided, and I'd like to get some RedHat variants in there. Therefore it is really designed for folks working on boost in some way, not those consuming it for their apps, although that is possible and will make it easier for folks that must build from source to meet requirements for their projects. The dependencies are the third party libraries that different boost modules use - some optionally, and some required, but all are included. In addition the environment to build the documentation is set up as part of the docker image so one has a complete build environment, however I'm not aware of any distro- specific packaging provided by boost itself, so that exercise is left up to the distro consumers. It came about because I was setting up my 5th or 6th boost development virtual machine due to hardware changes and I decided I didn't feel like going through it again. Now I can just install docker, build the docker image for the distro I want to work in, and off I go. I wasn't aware of the teeks99 dockerfile repository at the time. Given clang and gcc allow for layered installation, it would be easy to modify the dockerfiles here to include all of those compilers in one image, and then folks could use "toolset=" to select the one they want - however the clang toolset selector logic in b2 is substandard compared to gcc, so that needs to be worked on (I filed an issue in Boost.Build for this). Ideally I'd like to be able to provide a windows based docker build environment to make it easier to build on windows with all the required and optional third party libraries needed there. It's a lot more work to set up a windows build environment, but until Microsoft figures out they need to provide Visual Studio Build Tools that work on Windows Nano (<=600MB) instead of Windows Core (>3 GB), it's not that compelling. Of course, a complete environment for windows includes all of the compilers (MSVC 10, 11, 12, 14, 14.*) ideally so that one can build against all of them to make sure things work. This is what we've been leveraging in Appveyor through our repositories with CI. Having this (docker images and helper scripts) available in the superproject seems appropriate. Certainly the docker files, less certain about the shell scripts, since people usually customize them anyway, however a fair amount of work went into discovering the right set of command-line options to docker that allow one to debug inside the container effectively. The workflow I use is to have one shell in the container and one outside the container. The shell outside is used for git commands where your git identity is stored ( , although we could add another docker virtual mount that puts your user-specific git config into the container. Interesting...) jking@ubuntu:~$ cd boost jking@ubuntu:~/boost$ docker/run.sh ubuntu bionic boost@286b1533dac3:/boost$ cd libs/uuid boost@286b1533dac3:/boost/libs/uuid$ ../../b2 -q By default in the Ubuntu Bionic environment this will use the default toolset gcc which is gcc-7.3.0 in that environment. If you use the "debian stretch" environment it has gcc-6.3.0 in it. These are the default compilers that come with that distro and it is what consumers of boost will likely use. - Jim