Size optimize the VUnit images

[LukasVik]

Motivation: These docker images are used in CI in tsfpga and other projects. At the moment, in tsfpga, pulling the docker image represent a significant portion of the CI time. In order to save execution time, bandwidth and power, keeping docker images small should always be a priority.

In summary, -27 MB for the stable image, -75 MB for master image.

See the individual commits for details and some discussion around the individual changes.

[LukasVik]

Additionally, 115 MB could be saved in mcode images by not installing gcc and libc6-dev in run_debian.dockerfile. This does however affect the testsuite of ghdl. The following tests fail without gcc:

testsuite/gna/bug097
testsuite/gna/issue1226
testsuite/gna/issue1228
testsuite/gna/issue1233
testsuite/gna/issue1256
testsuite/gna/issue1326
testsuite/gna/issue450
testsuite/gna/issue531
testsuite/gna/issue98
testsuite/vpi/vpi001
testsuite/vpi/vpi002
testsuite/vpi/vpi003

All these tests seem to be testing VPI. However saving 115 MB from the mcode image is very tempting. That would make it very minimal, and perfect for CI.

It is not obvious to me that gcc should be included in the mcode docker image for the sake of being able to run vpi examples. I could add a mechanism to the GHDL testsuite so that these test do not run unless gcc is available on the system. In this scenario, if someone wants to use VPI, they would have to install a compiler of their choice on top of this image, or use ghdl/ghdl:gcc .

[eine]

Overall, I'm good with removing caches, avoiding COPY in the final images, and checking that installations are correct. I'm not sure about removing curl, make and gcc, for now. But let's discuss it further below.

[eine]

Additionally, 115 MB could be saved in mcode images by not installing gcc and libc6-dev in run_debian.dockerfile.

I believe this is the elephant in the room. As you guessed, GCC is added to mcode images for co-simulation purposes. When LLVM or GCC backends are used, GHDL can build C sources "internally". This allows providing VHDL sources and C sources, and let GHDL do the magic. With mcode, that's not possible, because it can only interact with pre-built shared libraries. Hence, a C compiler is required for users to convert their co-simulation C/C++ sources into a shared library. Providing it in the runtime image is convenient because it ensures that any image can be used for co-simulation with foreign languages.

Having said that, you are correct; we should not force all the users to download GCC, unless they need/want to.

I could add a mechanism to the GHDL testsuite so that these test do not run unless gcc is available on the system. In this scenario, if someone wants to use VPI, they would have to install a compiler of their choice on top of this image, or use ghdl/ghdl:gcc .

Please, go ahead. See examples of tests skipped for other reasons:

• https://github.com/ghdl/ghdl/blob/master/testsuite/sanity/005examples/testsuite.sh#L5-L9
• https://github.com/ghdl/ghdl/blob/master/testsuite/sanity/004all08/testsuite.sh#L3-L7
• https://github.com/ghdl/ghdl/blob/master/testsuite/gna/bug032/testsuite.sh#L3-L7

Related to previous comments about the purpose of these images, a few months ago some ghdl/cosim:* images were created. I think it makes sense now to make ghdl/vunit more specific, and create ghdl/cosim:mcode and ghdl/cosim:py. I propose the following roadmap:

• Skip tests in GHDL's testsuite if a C compiler is not available.
• Create ghdl/cosim:mcode, ghdl/cosim:py and ghdl/cosim:vunit-cocotb for replacing current ghdl/ghdl:*-mcode and ghdl/vunit:llvm* images.
• Remove GCC from ghdl/run:* images.
• Remove make and curl from ghdl/vunit:* images.

[LukasVik]

Please, go ahead.

I will get to it in the upcoming days. Maybe tomorrow, maybe next week.

Thank for your help!

[eine]

@LukasVik, BTW, you might like wagoodman/dive.

[LukasVik]

@LukasVik, BTW, you might like wagoodman/dive.

Yeah that tool is great. I used it a lot in this investigation.

[LukasVik]

I have cleaned up the commits and fixed all your suggestions. I think this PR is ready to merge.

[LukasVik]

I have created #34 for followup work so that this PR can be closed.