Docker support #643
Docker support #643
Conversation
| @@ -38,7 +38,7 @@ endif | |||
|
|
|||
| # To switch machines, simply switch the path of BSG_MACHINE_PATH to | |||
| # another directory with a Makefile.machine.include file. | |||
| BSG_MACHINE_PATH ?= $(BSG_F1_DIR)/machines/baseline_v0_32_16 | |||
| BSG_MACHINE_PATH ?= $(BSG_F1_DIR)/machines/4x4_fast_n_fake | |||
| @@ -98,8 +98,12 @@ endif # Matches: ifdef _BSG_MANYCORE_DIR | |||
| # Undefine the temporary variable to prevent its use | |||
| undefine _BSG_MANYCORE_DIR | |||
|
|
|||
| # If we're in the docker container, verilator is installed in /usr/bin/verilator | |||
There was a problem hiding this comment.
Is this because Verilator is installed through a package manager? It is best to use the one provided/compiled by bladerunner for parity.
There was a problem hiding this comment.
No, when building the Docker image it builds Verilator from source and installs it there.
There was a problem hiding this comment.
Do we have to install it there? Can we just leave it?
There was a problem hiding this comment.
I would rather be explicit that we're using the one in bladerunner, than install it in /usr/bin and be implicit.
There was a problem hiding this comment.
Well the point is to not have the user build Verilator themselves - they just download the image and it'll be preinstalled. We could just not install it and keep the binary in /verilator in the image, so we'd still be explicit.
drichmond
force-pushed
the
sasha_ubuntu
branch
from
cdcdb0b
to
1b3e879
Compare
drichmond
force-pushed
the
sasha_docker
branch
from
f55642f
to
37ddad4
Compare
| -v $(realpath $(shell pwd))/../:/bsg_bladerunner \ | ||
| --env BSG_PLATFORM=dpi-verilator \ | ||
| --env BSG_DOCKER=1 \ | ||
| --env RISCV_BIN_DIR=/usr/bin \ |
There was a problem hiding this comment.
Same for RISC-V Tools. I would rather use BSG_MANYCORE as the path, than use /usr/bin
There was a problem hiding this comment.
Same as with Verilator, BSG_MANYCORE lives in the user's filesystem, so this would be a bit difficult. We could again keep the RISCV_BIN_DIR in something like /riscv_install or similar.
|
I like the idea of this. But my fear is that the tool installation paths imposed by docker will introduce two different types of build flows, and conflicts between them. What we've learned is valuable though. The fixes for Ubuntu alone are worth it. |
|
Well it seems like all of the build flow is made in a location-agnostic way right? Every invocation to a tool is wrapped in a variable to its path, such as with verilator we have |
|
Actually I think there's a hack we could do - keep things installed in the root directory in the container but then symlink them in on entry into docker. Do you think that would be better? |
|
I like what you said about transparency. If there's a small number of Why is the |
|
The |
Adds a Makefile rule that in tandem with the other ubuntu support PRs will be able to run regression tests inside of Docker.