Subject: Re: [boost] Docker environment(s) for Boost Development
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2018-07-25 11:40:52
On 25 July 2018 at 12:50, James E. King III via Boost
> 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).
>> 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
>> What do you mean by "all the dependencies", Boost itself or deps required
>> by Boost?
> 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
That is exactly what I'm looking for.
The goal seems to be similar to Tom's.
> The dependencies are the third party libraries that different boost modules
> use - some optionally, and some required, but all are included.
eg. libjpeg, libpng for GIL, zlib for others, etc.
> 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.
I've been using Vagrant for long time, but docker seems suitable for
that purpose too,
especially after I experienced it via multi-docker build workflow on
(already used for Geometry and GIL).
> I wasn't aware of the teeks99 dockerfile repository at the time.
Ideally, if the community could agree to maintain single boostorg/docker
I'd like to be able to pull docker image(s), run regression tests and
submit to the Boost waterfall.
I'd also like to get some *BSD images - especially after long standing
failures of GIL on those systems.
Ideally, if I could run a script overnight that pulls images one by one
runs the tests and submits the results. I'm sure such automation is feasible.
> 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)
I've been using Vagrant to provide various Windows-based development
environments, and I feel the same pain.
> 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.
If there is boosorg/docker, then there will be documentation on boost.org.
I'll try to help.
-- Mateusz Loskot, http://mateusz.loskot.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk