[libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=178

--- Comment #187 from Jock Tanner <tanner.of.kha at gmail.com> ---
My working environment is finally set up.

I have fixed a typo regarding virtual environment activation in 6.5 of HDL
workflow. I also mentioned the dependencies (either python3-venv or
python-virtualenv) that was kinda taken for granted. I think now the
documentation is Buster-proof.

Maybe now it's a good time to script the whole process? Or is it not an issue?

I've also been thinking of up- and downsides of using chroot vs Docker vs
native OS packaging, and soon I have realized that the biggest downside of our
current setup is that it can be problematic for me to unleash the full
potential of my IDE on this project. By “full potential” I mean visual
debugging and inspection. I am using Pycharm, but this applies to any fairly
advanced IDE, like Eclipse/PyDev. They usually rely on ‘native’ (/usr/bin/) or
virtual (provided by virtualenv, conda et c.) Python prefixes for code
inspection, and chroot is neither of them.

So I started thinking about how to get rid of chroot. As I learned by delving
into #178, we are dealing with 4 categories of tools:

1. Native packages, provided by Debian repositories: binutils, gcc, clang,
python 2/3, latex, gtkwave et c.

2. Python packages provided by PyPI: jinja2 and sphinx. They are also present
in Debian repositories, so this category can be merged with 1 if necessary.

3. Binary packages than require bulding from source: alliance, coriolis 2,
yosys, symbiyosys.

4. Python packages that (at least their latest versions) are not in PyPI:
nmutil, nmigen, ieee754fpu, sfpy.

Category 1 can be used right away without chroot or any other isolation tool.
Isolation of categories 2 and 4 may be carried out with virtualenv, which is a
pythonista's good old friend. Category 4 may or may not require building, it
does not matter in this case. Only category 3 poses a problem.

When using virtualenv, $VIRTUAL_ENV directory can be used for building and
installing not only Python extensions, but roughly any FHS-compatible programs
and libraries. Basically you just have to supply --prefix=$VIRTUAL_ENV to the
build configuration script, and virtualenv magic do the rest. And you need no
system-wide configs, and no root access for this.

For example, xapian-haystack installs Xapian alone with its Python bindings
right in $VIRTUAL_ENV: https://github.com/notanumber/xapian-haystack/. (Xapian
itself written in C++ and do not require Python to work.)

How nice it would be if I could do the same with our category 3!

Sadly, this document
(https://www-soc.lip6.fr/sesi-docs/coriolis2-docs/coriolis2/en/html/users-guide/UsersGuide.html#fixed-directory-tree)
suggests that the build process of Coriolis 2 can not be tamed to my needs, at
least not so easy as with `--prefix=$VIRTUAL_ENV`.

Looks like I'm at the point of installing another copy of Pycharm into chroot.
Or is there some kind of an alternative solution that I did not consider?

-- 
You are receiving this mail because:
You are on the CC list for the bug.