Hi! This is a great project, thanks for the hard work on it!
Here's my question: I developed a couple of Python applications that use pyosys to do some synthesis/analysis work. Due to the nature of the host OS, packaging and distributing yosys to users of those tools is not a great experience at the moment. I feel like yowasp-yosys could improve that dramatically if it also allowed access to pyosys. This would also somehow fit nicely with the fact that it's being installed via a python package manager?
Being unfamiliar with wasm generally, I wonder if that's feasible at all, given pyosys depends on libyosys?
The text was updated successfully, but these errors were encountered:
It is infeasible. There's nothing I can do to allow it; the only way to get a WASM pyosys is to compile Yosys and Python to WASM together, in which case it'll work together with an isolated, ABI-incompatible version of Python embedded in the yowasp package.
wouldn't it be possible to compile libyosys (without the pyosys part) thru the wasi-sdk toolchain and expose an API similar to pyosys?
that's a bit different from the originally feature request and would likely leverage different tooling (https://github.com/bytecodealliance/wit-bindgen instead of pywrap) but it would fully the same goal (exposing a richer python in a cross platform compatible way).
In theory, yes, such bindings could eventually become a part of the YoWASP project. I would like to see them separate from yowasp-yosys; a distinct yowasp-libyosys repository and package seem like a good approach.
If someone would design and implement a prototype, under a different name of course, and it would match the quality of existing YoWASP projects, I would accept it under the umbrella and take up part of the maintenance, chiefly the release workflow. I would still need another maintainer to track the API changes.