Fixed root Dockerfile for building vtr container

[alirezazd]

Fixed broken Dockerfile script located at the project root.

Description

• The target image is now based on Ubuntu 20:04 LTS
• Build packages are now extracted from install_apt_packages.sh & requirements.txt files in VTR root
• Image build process is now in accordance with the latest build instructions available in VTR documenation.

Related Issue

#1756

Motivation and Context

As an option for building VTR, there is a docker container build script. VTR's fixed Dockerfile allows it to be built on different OSs and architectures effortlessly, by just running one command. This can especially be useful for building VTR on devices with Apple Silicon processors which currently lack native Linux support but support Linux-based docker containers.

How Has This Been Tested?

The fixed Dockerfile script now builds VTR sucessfully.

Types of changes

• Bug fix (change which fixes an issue)
• New feature (change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed

[mithro]

PTAL - @umarcor

[mithro]

We should add CI which makes sure that this Docker file continues to work?

[alirezazd]

We should add CI which makes sure that this Docker file continues to work?

Yes, I'll be wroking on it and I'm also intending to Update the related documentaton..

[umarcor]

Since this dockerfile is located in the root of the repo, users/developers do need to clone the repo already. Therefore, cloning it again inside the Dockerfile is redundant. I recommend to use BuildKit's mount features instead. See https://hdl.github.io/containers/dev/Contributing.html#buildkit and https://github.com/hdl/containers/blob/main/debian-bullseye/boolector/Dockerfile#L27.

[umarcor]

Overall, it is not desirable to install the dependencies and build VTR in the same docker build execution. That is particularly relevant if the dockerfile is to be used locally, to work around environment (host OS) limitations.

Instead, I'd suggest to use named stages and split dependency installation from building the tool (VTR here). That will allow to build the image with dependencies in CI and make it available through a registry. Then, users will only need to pull the image and build VTR, without installing all the deps again and again.

You can still use a single Dockerfile, but you need to use named stages.

Nonetheless, this is not specific to this PR, because the previous Dockerfile was already written like that. Hence, it can be addressed later.

[umarcor]

We should add CI which makes sure that this Docker file continues to work?

@mithro building to ensure that the Dockerfile works is trivial:

  Image:
    runs-on: ubuntu-latest
    env:
      DOCKER_BUILDKIT: 1
    steps:
    - uses: actions/checkout@v2

    - name: Build container image
      run: docker build -t test/vtr -f Dockerfile .

My recommendation would be to use ghcr, because it works with the default token. So:

  Image:
    runs-on: ubuntu-latest
    env:
      DOCKER_BUILDKIT: 1
    steps:
    - uses: actions/checkout@v2

    - name: Build container image
      run: docker build -t ghcr.io/verilog-to-routing/build -f Dockerfile .

    - name: Push container image
      uses: pyTooling/Actions/with-post-step@r0
      with:
        main: |
          echo '${{ github.token }}' | docker login ghcr.io -u GitHub-Actions --password-stdin
          docker push ghcr.io/verilog-to-routing/build
        post: docker logout ghcr.io

On the other hand, there is https://github.com/hdl/containers/blob/main/debian-bullseye/vtr.dockerfile#L24-L43 already.
That is based on Debian Bullseye, instead of Ubuntu 20.04.
I could publish that to gcr.io/hdl-containers as debian/bullseye/build/vtr, similarly to nextpnr or impl: https://console.cloud.google.com/gcr/images/hdl-containers/global/debian/bullseye/build.
Then, users might decide to use the one from ghcr based on Ubuntu or the one from gcr based on Debian.

[alirezazd]

@umarcor Thank you for your time and the detailed review. Most of your comments have been implemented. Currently, I'm reading BuildKit's docs in order to utilize the mount feature. I'll re-open the PR after completing.

Overall, it is not desirable to install the dependencies and build VTR in the same docker build execution. That is particularly relevant if the dockerfile is to be used locally, to work around environment (host OS) limitations.

Instead, I'd suggest to use named stages and split dependency installation from building the tool (VTR here). That will allow to build the image with dependencies in CI and make it available through a registry. Then, users will only need to pull the image and build VTR, without installing all the deps again and again.

You can still use a single Dockerfile, but you need to use named stages.

Nonetheless, this is not specific to this PR, because the previous Dockerfile was already written like that. Hence, it can be addressed later.

Yes, I agree with you. I just fixed the Dockerfile according to its current structure, since I was trying to build VTR on MAC and did not have native Linux support. I'll rewrite the Dockerfile and implement the structure you mentioned in a future PR (if someone doesn't accomplish it sooner).

[alirezazd]

@umarcor I applied your reviews as much as I could; however, I could not apply following:

1. Could not remove ARG DEBIAN_FRONTEND=noninteractive since I could not hardcode it in xargs (check Line 13).
2. Tried to use build kit's mount feature instead of cloning the repo, but could not build with cmake nor make because of not having write permissions (tired -- prefix and cmake -DCMAKE_INSTALL_PREFIX:PATH=/workspace to change the build path but did not work). I used COPY instruction as a workaround.

[umarcor]

@alirezazd:

1. It's ok. It's not worth fighting with it now; better deal with it when the script is improved.
2. The mount feature is read-only, indeed, so you need to first copy the content to e.g. /tmp and then work there. Anyway, that's also not critical. Using COPY in this PR is acceptable.

[alirezazd]

@mithro This PR is ready to merge, JFYI.