This involves very few changes, all typical to WASM ports:
* WASM doesn't currently support threads or atomics so those are
disabled.
* WASM doesn't currently support exceptions so the exception
machinery is stubbed out.
* WASM doesn't (and can't) have mmap(), so an emulation library is
used. That library currently doesn't support MAP_SHARED flags,
so MAP_PRIVATE is used instead.
There is also an update to bring ECP5 bbasm CMake rules to parity
with iCE40 ones, since although it is possible to embed chipdb into
nextpnr on WASM, a 200 MB WASM file has very few practical uses.
The README is not updated and there is no included toolchain file
because at the moment it's not possible to build nextpnr with
upstream boost and wasi-libc. Boost requires a patch (merged, will
be available in boost 1.74.0), wasi-libc requires a few unmerged
patches.
If the user specifies a custom install prefix, chances are icestrom/trellis
are also in that prefix rather than the hardcoded /usr/local
Fixes#351
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
two other commit message of squashed commits:
CMake: Search for user lib inside trellis instead of libtrellis
CMake: Fix missing path component for share contents
Follows PM discussion with Marcus Comstedt.
Extend changes in .bba file location (made in commit b6a7b60) to ice40 and MSVC cases,
so all cases become compatible with read-only access to git tree.
Only known down-side is inefficiency when building out-of-tree for multiple architectures;
people following that use case should consider using PREGENERATED_BBA_PATH.
It would be nice if there were less copy-paste in MSVC vs. non-MSVC content in family.cmake,
but that would have to be addressed by someone more skilled in Cmake and MSVC.
With this change, nextpnr can build successfully (and run correctly) using the git tree as a read-only reference.
No change in behavior observed for in-tree builds.
Sometimes the python executable might have a different name. Cmake
sets the $PYTHON_EXECUTABLE variable to point to the binary path,
so use this variable.
Signed-off-by: Sean Cross <sean@xobs.io>
If a distro-specific "trellis-devel" package is used, the
pytrellis.so library might be located in a dedicated directory,
rather than under TRELLIS_ROOT.
Search for pytrellis.so in a list of directories, then subsequently
use the first match as part of PYTHONPATH.
Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>
