9dedac50 introduced this harmless but disconcerting warning, which was emitted
when abc/ did not yet exist and was about to be cloned:
/bin/sh: line 0: cd: abc: No such file or directory
This includes the following significant changes:
* Patching ezsat and minisat to disable resource limiting code
on WASM/WASI, since the POSIX functions they use are unavailable.
* Adding a new definition, YOSYS_DISABLE_SPAWN, present if platform
does not support spawning subprocesses (i.e. Emscripten or WASI).
This definition hides the definition of `run_command()`.
* Adding a new Makefile flag, DISABLE_SPAWN, present in the same
condition. This flag disables all passes that require spawning
subprocesses for their function.
By operating at a layer of abstraction over the rather clumsy Intel primitives,
we can avoid special hacks like `dffinit -highlow` in favour of simple techmapping.
This also makes the primitives much easier to manipulate, and more descriptive
(no more cyclonev_lcell_comb to mean anything from a LUT2 to a LUT6).
The make targets echo-yosys-ver, echo-git-ver and echo-abc-rev can be
used to programmatically extract contents of make variables for external
scripts. Unfortunately, when a Makefile.conf exists, its contents would
also be echoed, making the output almost unusable. This patch
selectively disables this functionality for these special targets.
`rev-parse --short` output may have a different abbreviated hash length than
ABCREV, so a simple string comparison always fails, even if the correct
commit is checked out. Pass both commits through rev-parse and then
compare the full hashes instead.
Add an `echo-abc-rev` target so that packaging scripts can set ABCPULL=0 and
handle all the git nastiness themselves.
`rev-parse --short` output may have a different abbreviated hash length than
ABCREV, so a simple string comparison always fails, even if the correct
commit is checked out. Pass both commits through rev-parse and then
compare the full hashes instead.
Add an `echo-abc-rev` target so that packaging scripts can set ABCPULL=0 and
handle all the git nastiness themselves.
The behaviour of python-config --libs has changed in Python 3.8.
For example, compare the output of it with Python 3.7 and 3.8 on an
ArchLinux system:
$ python3.7-config --libs
-lpython3.7m -lcrypt -lpthread -ldl -lutil -lm
$ python3.8-config --libs
-lcrypt -lpthread -ldl -lutil -lm -lm
$
The lack of -lpython in the latter case causes the linker to fail when
attempting to build Yosys against Python 3.8.
Passing the new --embed flag to python-config adds -lpython, just like
earlier versions of Python:
$ python3.8-config --embed --libs
-lpython3.8 -lcrypt -lpthread -ldl -lutil -lm -lm
$
This commit adds code for automatically detecting support for the
--embed flag. If it is supported, it is passed to all python-config
invocations. This fixes building against Python 3.8.
On some architectures, notably on Windows, the official name for the
Python binary from python.org is `python`. The build system assumes
that python is called `python3`, which breaks under this architecture.
There is already infrastructure in place to determine the name of the
Python binary when building PYOSYS. Since Python is now always required
to build Yosys, enable this check universally which sets the
`PYTHON_EXECUTABLE` variable.
Then, reuse this variable in other Makefiles as necessary, rather than
hardcoding `python3` everywhere.
Signed-off-by: Sean Cross <sean@xobs.io>
whitequark
Xiretza
Eddie Hung
N. Engelhardt
Claire Wolf
Dan Ravensloft
Miodrag Milanovic
Claire Wolf
Alberto Gonzalez
jiegec
Rodrigo Alejandro Melo
Graham Edgecombe
Pepijn de Vos
Sean Cross