Re: [boost] Docker environment(s) for Boost Development

Subject: Re: [boost] Docker environment(s) for Boost Development
From: James E. King III (jking_at_[hidden])
Date: 2018-07-25 10:50:32

On Wed, Jul 25, 2018 at 5:41 AM Mateusz Loskot via Boost <
boost_at_[hidden]> 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_at_ubuntu:~$ cd boost
jking_at_ubuntu:~/boost$ docker/run.sh ubuntu bionic
boost_at_286b1533dac3:/boost$ cd libs/uuid
boost_at_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