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@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?
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