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

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
<boost_at_[hidden]> wrote:
> 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?
>
> 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.
Makes sense.

> 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
CircleCI 2.0
(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.

Yes.

> 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.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net