Feature/python bindings

[christian-krieg]

Python bindings to interact with the Yosys C++ API Yosys from within Python. This feature enables to call Yosys data structures and functions from a Python script, and to call passes written in Python from the Yosys shell.

[daveshah1]

Arch Linux calls the Boost Python library boost_python37 rather than boost_python-py37. There is significant inter-distro variation here, see all the different cases that we ended up having to detect in nextpnr: https://github.com/YosysHQ/nextpnr/blob/master/CMakeLists.txt#L132-L186 - I'm not sure if there is a better way than bruteforcing all the possibilities here.

[btut]

Thanks for the heads-up. I implemented 4 versions now:

1. boost_python-py
2. boost_python-py<major_version>
3. boost_python
4. boost_python<major_version>

If none of those work, the user is prompted to define BOOST_PYTHON_LIB manually.
cc270ea

[daveshah1]

Thanks, this works well for me now. One small comment is the auto-detection prints

/usr/bin/ld: cannot find -lboost_python-py37
collect2: error: ld returned 1 exit status
/usr/bin/ld: cannot find -lboost_python-py3
collect2: error: ld returned 1 exit status
/usr/bin/ld: cannot find -lboost_python-py37
collect2: error: ld returned 1 exit status
/usr/bin/ld: cannot find -lboost_python-py3
collect2: error: ld returned 1 exit status

at the moment, which could be confusing as it looks like an error. Perhaps you should redirect the output to /dev/null or similar?

[btut]

Suppressed error output in e19981a

[daveshah1]

Thanks for the reminder @cliffordwolf !

Generally very happy with this now. My last remaining issue is that as far as I can tell, this is enabled by default for all Yosys targets. It would be good to confirm that it works for all of them (e.g. mxe, msys2, Emscripten, Visual Studio) and if not, either fix it or disable it by default if it isn't practicable to get it to work (I suspect this may be the case for Emscripten at least).

[cliffordwolf]

I've now merged it, but also set ENABLE_PYOSYS=0 as default value.

[cliffordwolf]

I'd like to keep the root dir as clean as possible. Would it be possible to move __init__.py and py_wrap_generator.py to misc/, maybe make __init__.py a make target and only place it in the top-level dir if we are actually performing a build with python enabled?

[btut]

I'd like to keep the root dir as clean as possible. Would it be possible to move __init__.py and py_wrap_generator.py to misc/, maybe make __init__.py a make target and only place it in the top-level dir if we are actually performing a build with python enabled?

This is a simple fix. No need for a build-target for init.py, as it is not needed when importing the .so file from the yosys directory, just when it is installed, so copying it on install (from the misc dir) is enough.
I am not a github pro, is there any way to update this pull-request with a new commit?

My last remaining issue is that as far as I can tell, this is enabled by default for all Yosys targets. It would be good to confirm that it works for all of them

I need to setup a lot of virtual machines to test this out, unfortunately this will take some time.

[cliffordwolf]

I am not a github pro, is there any way to update this pull-request with a new commit?

No, but you can just push to your existing branch and create another PR. But usually one would create a new feature branch, forked from current master, and create a new PR. (This sounds like a hassle but it's really just a few seconds once you are used to git.)

I need to setup a lot of virtual machines to test this out, unfortunately this will take some time.

I did turn it off by default for now. So no need to get wild with testing on all platforms yet.

[btut]

But usually one would create a new feature branch, forked from current master, and create a new PR.

I stuck to the same feature-branch for now since I already pushed to it before you commented, but will keep your suggestion in mind for next time. Thanks!