Subject: Re: [boost] Docker environment(s) for Boost Development
From: Tom Kent (lists_at_[hidden])
Date: 2018-05-09 23:53:10
On Tue, May 8, 2018 at 6:59 AM, James E. King, III via Boost <
> I submitted a pull request into the superproject containing some docker
> scripts. The intention of this is to simplify managing a docker build
> environment for boost:
> I'm wondering if folks will find this useful, and whether folks think this
> should be in its own submodule instead of being in boostorg/boost. I only
> have an Ubuntu Bionic environment in this pull request but it wouldn't be
> that difficult to add debian, centos, and others, as well as various
> versions of each.
> I have tested it on Unix and on Windows. On Unix the performance is quite
> good overall - but on Windows since they use SMB to do the sharing it is
> really slow (I would say a good 20 times slower between typing "b2" and
> getting the first output as it scans through all the files. I would
> recommend continuing to use a virtual machine on Windows Hosts for unix
> boost development, but this option is there and hopefully they will improve
> 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).
> One day when Microsoft supports Visual Studio compilation inside a
> reasonably sized windows container (i.e. based on nanoserver and not
> Windows Server Core), I'd like to add that as well since managing the
> dependencies on Windows is a bit harder (you usually have to build them).
I just wanted to mention that I've got a stable of boost docker images
built from the git repo:
I initially created these as the source for the linux regression runners
that I manage (teeks99-02*, teeks99-03*), but have used them for a lot
more. They are more focused on having older versions of compilers (gcc and
clang) working, and I think is largely complimentary to what you have here.
Just wanted to mention it in this thread.
Another thought, it might be a nice idea to take what you've done for the
baseline to create an environment, and for each release build the release
version of boost inside it and publish it to docker hub. This would give
users a way to quickly get a boost development environment, without having
to wait for the distros to package (and mangle) the binaries.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk