Apification#3
Open
ArkoshEternal wants to merge 12 commits into
Open
Conversation
parse_args resolves command-line parameter overrides (e.g. --PARAM=val) into the EDAM parameters dict. Filters that need the resolved parameter values (such as elaboration-based lowering filters reading vlogparam defaults) see stale .core defaults when apply_filters runs first. Swap the order so filters always see the fully resolved parameter state. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
All other paths in fusesoc.conf are supposed to be relative to the location of the config file. This was not the case for library locations
Flag values were assumed to be bool/None or already-string. A numeric
value (e.g. ``flags: { blah: 1234 }`` in a target, which YAML parses
as int) raised a TypeError from ``k + "_" + v`` deep inside the
expression expander, with no useful context for the user.
The CAPI2 schema already allows ``any_type`` (including number) for
flag values, so coerce anything that isn't a bool/None to its
``str()`` representation before joining it with the flag key. This
makes ``flags: { blah: 1234 }`` behave like
``flags: { blah: "1234" }``, defining the flag ``blah_1234``.
Fixes olofk#683.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
``fusesoc core-info a/b`` (or any other command taking a VLNV with a ``/`` in it) crashed with a multi-frame Python traceback ending in ``simplesat.errors.InvalidConstraint``, because the slash made it through ``Vlnv`` parsing untouched and only blew up later inside simplesat's tokenizer. Validate vendor/library/name/version after parsing and raise a clean ``SyntaxError`` if any of them contain characters outside the set ``[A-Za-z0-9_.-]``. This produces a one-line, actionable error instead of a stack trace pointing into a third-party dependency, and catches other unsupported characters (whitespace, ``*``, etc.) at the same boundary. Fixes olofk#749. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Edalize generates one Makefile target per hook script using the script's ``name`` field. When two cores in the dependency tree defined a hook script with the same name (typical when a child core inherits/overrides a hook from a parent), both ended up in the merged EDAM ``hooks`` list with identical names, so the Makefile got duplicate targets and only the last one was actually run -- silently dropping the inherited hook. Fix it on the FuseSoC side by prefixing every emitted hook script's ``name`` with the owning core's ``sanitized_name`` in ``Edalizer.create_edam``. ``Core.get_scripts`` keeps returning the user-facing name unchanged, since other call sites and the existing test_capi2 expectations rely on that. The prefixing happens only at the EDAM emission boundary, where the owning-core context is available. Adds a regression test using a small two-core fixture in which the parent and child both define a script called ``myhook``; the test asserts that the resulting EDAM ``hooks.pre_build`` list has two distinct names rather than two collisions. Fixes olofk#646. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
When ``CoreManager.find_cores`` encounters a ``.core`` file that fails
the CAPI2 schema validation it logs a warning and skips the file. If
the user later asks for a core that happens to be the one which
failed, all they see is::
ERROR: '::mycore:0' or any of its dependencies requires 'mycore',
but this core was not found
The original parse-error warning has long since scrolled off-screen
amid other library-scan output, leaving the user with a misleading
"not found" message that hides the real cause (a malformed .core file
in their tree). This bites every user who has even one broken file in
their search path.
Track the ``(core_file, error_message)`` pairs on ``CoreManager`` (and
expose them via ``Fusesoc.parse_errors``) and append them to the
"core not found" message in ``main._get_core``. Real-time warnings
keep working as before; this just keeps the original cause visible at
the moment the user actually needs it.
Fixes olofk#761.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ArkoshEternal
force-pushed
the
apification
branch
from
June 15, 2026 15:07
9c7708d to
ade089b
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
API-ification
Purpose:
Attempt to clean up some of the functionality that has crept into main and instead center it in fusesoc