Remove the need to set environment values after install

[mithro]

Currently, after installing you need to set the following environment values;

         export PATH="$INSTALL_DIR/$FPGA_FAM/install/bin:$PATH";
         source "$INSTALL_DIR/$FPGA_FAM/conda/etc/profile.d/conda.sh"

This should not be needed and causes a huge amount of confusion amount users.

[umarcor]

FTR, if containers from hdl/containers are used, setting those environment values is not required:

https://github.com/SymbiFlow/symbiflow-examples/pull/220#issuecomment-992101880

:~# git clone https://github.com/SymbiFlow/symbiflow-examples
...
:~# cd symbiflow-examples

:~/symbiflow-examples# docker run --rm -it \
  -v /$(pwd)://wrk \
  -w //wrk \
  gcr.io/hdl-containers/symbiflow/xc7/a100t
...
root@c3d4dd1d97cc:/wrk# conda activate xc7
...
(xc7) root@c3d4dd1d97cc:/wrk# TARGET="arty_100" make -C xc7/picosoc_demo/

On the containers, the toolchain is available in the PATH already, and the script is sourced implicitly. Hence, users only need to activate the conda environment.

[pgielda]

I agree with Tim its confusing. I disagree that hiding in a container is better. You suddenly need to use docker which makes it even more convoluted. I like the idea to have an alternative with e.g. docker, but examples were supposed to show what to install not hide it completely in a container. I think we can probably improve easily to at least remove the PATH requirement.

[umarcor]

@pgielda, I don't claim that using containers is better. However, it is faster and easier to update, particularly in CI. Therefore, it can be interesting for users who want to quickly use SymbiFlow without dealing with installing the Conda environment from scratch. That is not a solution to this issue, but informative.

For reference, in https://github.com/SymbiFlow/symbiflow-examples/actions/runs/1575664117 "Install SymbiFlow toolchain" needs 14 min. Conversely, in https://github.com/umarcor/symbiflow-examples/actions/runs/1576528548 pulling a container needs 1.5-2 min.

I agree that a cleaner solution would be for containers not to use Conda at all. That requires going through the list of utilities that compose SymbiFlow, and checking how to build each of them standalone (outside of Conda). Some of those are available in hdl/containers already, others are not. Therefore, installing SymbiFlow in containers through Conda is a temporary solution. That provides a foundation to work on the makefiles here and/or in SymbiFlow/make-env, in order to wrap individual tools as done in fomu-workshop: container.mk. Actually, FuseSoC/Edalize uses the same approach (https://carlosedp.medium.com/xilinx-open-source-fpga-toolchain-on-docker-containers-93202650a615), which is based on the makefiles from ghdl-yosys-plugin and microwatt.

[pgielda]

Let me rephrase, what @mithro mentions is an issue with additional env variables that maybe we can improve to not have to define.

What you propose is a change in the approach and a different discussion. By design this repo ("symbiflow-examples") was/is supposed to show users how to install Symbiflow toolchain(s) using conda (a packaging system that is distro-independent) on multiple different distros and then how to use the toolchain with a range of example designs.

Btw maybe I am alone here but I personally (as a user) would not care if the containers are built by using conda inside or not. The whole point of the containers is a little bit that you do not care whats inside as long as it works. Its a glorified "wget a big rootfs + chroot + forget" in many cases.

And do not get me wrong, I like containers. I am just explaining rationale behind what symbiflow-examples tries/tried to be. I think this discussion could be moved into a separate issue tbh.

[umarcor]

See #227

[carlosedp]

Agreed, I believe the container images should be all set just to be able to run each tool without all the download/install/setup and dependency dance. Without having additional steps like running a shell, calling activate and etc.

As an example, we have a wrapper script to FuseSoc's Edalize (https://gist.github.com/carlosedp/c0e29d55e48309a48961f2e3939acfe9) where for each tool called, the wrapper calls a Docker container based on an image that already have the tool running.

This allows the user to run the full workflow without having local tools (except programming the board).

Ref issue: https://github.com/hdl/containers/issues/49

Gist

FuseSoc launcher wrapper for containerized commands

FuseSoc launcher wrapper for containerized commands - runme.py

[carlosedp]

@umarcor .. isn't it possible to activate the conda environment thru a docker-entrypoint script or something like that beforehand?

Something like:

#!/bin/bash

source "/opt/conda/etc/profile.d/conda.sh"

exec "$@"

Having the images without the env set kinda complicates things a bit.

[umarcor]

@carlosedp, see https://github.com/hdl/containers/issues/49#issuecomment-995491061. In gcr.io/hdl-containers/conda/symbiflow images, the environment is automatically activated through profile.d.