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>
A new pass, connect_rpc, allows any HDL frontend that can read/write
JSON from/to stdin/stdout or an unix socket or a named pipe to
participate in elaboration as a first class citizen, such that any
other HDL supported by Yosys directly or indirectly can transparently
instantiate modules handled by this frontend.
Recognizing that many HDL frontends emit Verilog, it allows the RPC
frontend to direct Yosys to process the result of instantiation via
any built-in Yosys frontend. The resulting RTLIL is then hygienically
integrated into the overall design.
Problems/questions:
- fsm.ys. equiv_opt -assert failed because of unproven cells;
- latches.ys,tribuf.ys - internal cells present;
- memory.ys - sat called with -verify and proof did fail.
Problems/questions:
- memory.ys: ERROR: Failed to import cell gate.mem.0.0.0 (type
EG_LOGIC_DRAM16X4) to SAT database.
Why EG_LOGIC_DRAM16X4, not AL_LOGIC_BRAM?
- Internal cell type $_TBUF_ is present.
Did you think that `$(shell command -v ...)` would actually get run by
the shell? Foolish mortal; GNU Make is obviously far more wise than
thee, as it optimizes it to a direct -- and hence broken (since
`command` is a shell builtin) -- exec. This horrifying contortion
ensures that an actual shell runs the command and fixes the behaviour.
@Shizmob found the source of this misbehaviour; turns out gmake has a
hard-coded, incomplete list of shell builtins:
715c787dc6/src/job.c (L2691)
This contains `command`, but the whole function is full of horrible
heuristic garbage so who knows. I'm so sorry.
Graham Edgecombe
Pepijn de Vos
Sean Cross
Miodrag Milanovic
SergeyDegtyar
Clifford Wolf
David Shah
Sergey
Eddie Hung
whitequark
Emily