Conditionally include help source tracking to preserve ABI.
Docs builds can (and should) use `ENABLE_HELP_SOURCE` so that the generated sphinx docs can perform default grouping and link to source files.
Regular user-builds don't need the source tracking.
Use `chformal` as example, comparing the `autocmd` output with `ChformalPass::formal_help()`, the json dump from the `ContentListing`, the command line output, and the RST generated (using `autocmd_rst`).
Includes bullet points on each step for more information.
Should eventually end up in `yosys_internals/extending_yosys/contributing.rst`, but it currently lives in `cmd/index_internal.rst` to avoid merge conflicts since cell help documentation is still WIP.
Also exports chformal source and help output to `docs/source/generated` during `make docs/prep`.
Use `std::experimental::source_location` because clang support is `??`
Add `ENABLE_SOURCE_LOCATION` make variable and corresponding `YOSYS_ENABLE_SOURCE_LOCATION` define.
Dummy out the struct if disabled and check for null instead of using `#ifdef` blocks everywhere.
Define `PrettyHelp` class with methods for declaring different parts of help message.
Currently able to produce standard help messages as expected.
Updates chformal to use (only) the new help_v2.
Currently makes use of a global static to track the current help context, allowing register.h to live in blissful ignorance and instead rely on help_v2 implementations calling `auto *help = PrettyHelp::get_current();` and `return true;` to minimise impact on rebuilds (i.e. not requiring every source file to be recompiled).
Using `:=` while providing an override (either in Makefile.conf or on the command line) does not correctly apply the override in other simply expanded variables (using `:=`). Instead, passing an explicit `PYTHON_EXECUTABLE=python3.15` while leaving `PYTHON_CONFIG` implicitly defined results in it being set to `python3-config` instead of the expected `python3.15-config`.
For some platforms (Arch Linux, at least), `git status` reports errors on stdout instead of stderr, so we need to redirect that to `/dev/null` too. This also prevents `git status` from logging output when the yosys directory is a git repo, but is missing the abc folder.
Partially reverts commit 9c5bffcf93.
The reasoning behind this is that setup.py is intended to strictly consume the Makefile and not be consumed by it. The attempt at using them recursively has caused a number of issues and has rendered Pyosys unusable to some users: See https://github.com/YosysHQ/yosys/issues/5012
Additionally, unlike the previous pyosys installation target, the wheel installation does not respect PREFIX=, only venvs.
For installation inside a venv, the intended method should remain a user manually executing `pip3 install .` instead of relying on the Makefile.
Essentially, something is attempting to build the Yosys EXE when you build libyosys.so now. With `ENABLE_PYTHON_CONFIG_EMBED=0`, the Yosys EXE will always fail to build.
Furthermore, because `ENABLE_PYOSYS` now attempts to build a wheel, building a wheel has become recursive.
This commit uses a supplementary set of libs for the EXE (EXE_LIBS) so it and libyosys.so can be built simultaneously, as well as a new Makefile flag, `ENABLE_WHEEL`, to prevent the aforementioned recursion.
I also enabled aarch64 Linux in the CI because it's publicly available now.
As in #4986, `check-git-abc` is misleading if Yosys itself isn't a git repository.
So check `git status` before suggesting `git` based solutions, providing alternative suggestions for using ABCEXTERNAL (which bypasses `check-git-abc`), or downloading release tar (noting that the 'Source code' archives won't work, which is probably how they ended up in this situtation).
Make will happily consider a target available if it's zero sized.
When writing output files with shell redirections for commands that usually
succeed we can apply the `|| rm $@` pattern.
For commands where --help exits with failure we always rerun the recipe
instead.
As the intro paragraph (now) says:
> This section will introduce the SMT-LIB functional backend and what changes are needed...
The example is intended to be read without prior knowledge of the SMT-LIB backend, but the previous version glossed over a lot and instead focused on *just* what was changed.
This version should now be easier to follow without prior knowledge, while still being able to learn enough about the `Smt` version to adapt it to a different s-expression target that isn't Rosette.
Also adds a few `literalinclude`s of smtlib.cc, which is now copied to `docs/source/generated` along with producing the rosette diff on the fly (which now also has up to 20 lines of context, enabling the full `Module::write()` diff to be literal included).
`python-config --ldflag` includes output of `python-config --libs`; and the `$(CXX)` call in `CHECK_BOOST_PYTHON` still needs those libs.
Move all of the `$(shell $(PYTHON_CONFIG) ..` lines to the top of the block.
Covering all the bases, I guess? '-'-prefix is already correctly handled by the base case message.
If the user somehow gets merge conflicts in abc, hopefully they know what they're doing.
A '+'-prefix means that the submodule is initialized and checked out, but a different commit is checked out.
If this is accidental then the user should run `git submodule update` to fix it.
If it is intentional (because e.g. the user is explicitly wanting to test Yosys with a different version of abc), then creating a new commit in Yosys to update the expected commit is also a valid solution.
- Techlib pmgens are now in relevant techlibs/*.
- `peepopt` pmgens are now in passes/opt.
- `test_pmgen` is still in passes/pmgen.
- Update `Makefile.inc` and `.gitignore` file(s) to match new `*_pm.h` location,
as well as the `#include`s.
- Change default `%_pm.h` make target to `techlibs/%_pm.h` and move it to the
top level Makefile.
- Update pmgen target to use `$(notdir $*)` (where `$*` is the part of the file
name that matched the '%' in the target) instead of `$(subst _pm.h,,$(notdir
$@))`.
The B port is for single-bit summands. These can just as well be
represented as an additional summand on the A port (which supports
summands of arbitrary width). An upcoming `$macc_v2` cell won't be
special-casing single-bit summands in any way.
In preparation, make the following changes:
* remove the `bit_ports` field from the `Macc` helper (instead add any
single-bit summands to `ports` next to other summands)
* leave `B` empty on cells emitted from `Macc::to_cell`
In commit ac988cf we made sure to undefine the CONST/VOID macros left
defined by `tcl.h`, but this in turn makes it an issue to include
additional Tcl headers later on (see issue #4808).
One way out is to avoid a global `tcl.h` include. In the process we drop
support for Tcl-enabled MXE builds, which were likely broken anyway due
to the additional Tcl APIs used from `tclapi.cc`.