chore: add missing bench task config to complex/float64/base/assert/is_equal

[Om-A-osc]

---

type: pre_commit_static_analysis_report
description: Results of running static analysis checks when committing changes. report:

• task: lint_filenames status: passed
• task: lint_editorconfig status: passed
• task: lint_markdown status: na
• task: lint_package_json status: na
• task: lint_repl_help status: na
• task: lint_javascript_src status: na
• task: lint_javascript_cli status: na
• task: lint_javascript_examples status: na
• task: lint_javascript_tests status: na
• task: lint_javascript_benchmarks status: na
• task: lint_python status: na
• task: lint_r status: na
• task: lint_c_src status: na
• task: lint_c_examples status: na
• task: lint_c_benchmarks status: na
• task: lint_c_tests_fixtures status: na
• task: lint_shell status: na
• task: lint_typescript_declarations status: passed
• task: lint_typescript_tests status: na
• task: lint_license_headers status: passed

---

Resolves #N/A.

Description

What is the purpose of this pull request?

This pull request:

• Adds missing benchmark configuration to complex/float64/base/assert/is_equal.
• While working on another package, I encountered issues running C benchmarks due to the missing benchmark configuration in the manifest.
• This change ensures benchmarks are properly recognized and executable.

Related Issues

Does this pull request have any related issues?

This pull request has no related issues.

Questions

Any questions for reviewers of this pull request?

No.

Other

Any other information relevant to this pull request? This may include screenshots, references, and/or implementation notes.

No.

Checklist

Please ensure the following tasks are completed before submitting this pull request.

• Read, understood, and followed the contributing guidelines.

AI Assistance

When authoring the changes proposed in this PR, did you use any kind of AI assistance?

• Yes
• No

Disclosure

N/A.

---

@stdlib-js/reviewers

[stdlib-bot]

Coverage Report

Package	Statements	Branches	Functions	Lines
complex/float64/base/assert/is-equal	$\color{green}100/100$ $\color{green}+100.00%$	$\color{green}4/4$ $\color{green}+100.00%$	$\color{green}1/1$ $\color{green}+100.00%$	$\color{green}100/100$ $\color{green}+100.00%$

The above coverage report was generated for the changes in this PR.

[Om-A-osc]

@Planeshifter Please have a look whenever possible.

[Planeshifter]

That's very weird: the benchmark task in the manifest is used to compile native C code for benchmark/benchmark.native.js and benchmark/c/benchmark.c, but this package has neither of those files. I don't understand how you might have encountered an error due to this configuration being missing. Please elaborate; otherwise we should go ahead and close this PR.

[Om-A-osc]

Thanks for looking into this. @Planeshifter

The failure I encountered is not related to this package having its own
benchmark/c or benchmark.native.js files. The issue appears when
another package (zgemv) compiles its C benchmarks and includes this
package as a dependency.

What actually failed

Running:

make BENCHMARKS_FILTER=".*/blas/base/zgemv/.*" benchmark-c

failed while compiling the zgemv C benchmark because the header

stdlib/complex/float64/base/assert/is_equal.h

could not be found.

Why it failed

The stdlib build system uses @stdlib/utils/library-manifest to resolve
include paths and sources for a specific task (e.g., build,
benchmark, examples).

When resolving dependencies, the resolver requires an exact task
match.

From the debug output during dependency resolution:

Provided conditions: {"os":"linux","task":"benchmark"}
Conditions for matching a configuration: {"task":"benchmark"}
Resolving matching configuration.
Unable to resolve a matching configuration.
Dependency manifest: {}

This shows:

1. The resolver requested the benchmark task.

2. The is-equal manifest only defines:

   • build
   • examples

3. Because no benchmark configuration exists, the resolver returned:

   {}
   

4. As a result:

   • its include directory was not merged
   • the compiler never received the header path
   • compilation failed

Why this only appears during benchmarks

Node addon builds succeed because they do not compile the C benchmark
sources.

The failure appears only when compiling pure C benchmarks, which
include:

#include "stdlib/complex/float64/base/assert/is_equal.h"

Header resolution for these builds depends entirely on the manifest
resolver.

Why the absence of benchmark files is unrelated

The benchmark task in a manifest is not only for building this
package’s benchmarks.

It is also used when:

• another package builds benchmarks
• and depends on this package
• and requires its headers/sources for that task

So even though is-equal has no benchmarks, it still needs to resolve
correctly when used by benchmark builds in dependent packages.

Minimal reproduction logic

Given:

is-equal manifest

• supports: build, examples
• no benchmark

zgemv benchmark task

• depends on @stdlib/.../is-equal

Why the change fixes the issue

Making the manifest task-agnostic (or adding a benchmark
configuration) allows the dependency to resolve for benchmark builds,
ensuring its headers are available.

Why this may not have surfaced earlier

This only occurs when:

• a C benchmark includes a dependency header
• the dependency uses task-specific configs
• and lacks a matching task entry

This combination is relatively uncommon.

[Om-A-osc]

@Planeshifter @kgryte I tried to explain the issue I am facing as simply as possible. Please correct me if I am understanding anything wrong.

[kgryte]

The reported issue is legitimate; however, @Planeshifter is right that adding this configuration feels incorrect.

The underlying issue is actually more general. Namely, we need manifest.json files to include a "base" configuration in order to enumerate deps and source files independent of benchmarks, examples, or native add-ons. This "base" configuration would be what is resolved when a package is a dependency.

Currently, we "over"-resolve dependencies. E.g., when compiling a native add-on, we resolve the native add-on dependencies for all dependencies of a perspective package when, in fact, we only need to resolve the native add-on dependencies for the top-level package which is being compiled. For all the dependencies, we only need the list of source files and their immediate dependents.

Fixing this will require effectively updating all manifest.json files across the project. This has been known for a while, but we've gotten away with not addressing it because C packages have typically had benchmarks, examples, and a native add-on, so we've been able to "correctly" resolve source files of dependents. This was the first case where that hasn't been true.

[Om-A-osc]

@kgryte While working on zgemv, I somehow managed to stumble into this rare edge case. I’m starting to think I have a special talent for attracting complex build issues.

However For this PR, I see a few options:

Add a C benchmark to the package as a workaround.

Merge with a benchmark config but no benchmarks.

Introduce the proposed base manifest configuration (the correct long-term fix, but requires widespread manifest updates).

modify library-manifest to gracefully fallback to the "build" task for any dependency that does not satisfy the current conditions (like benchmark or test). ( I was trying this and it seems to work nicely )

Let me know which direction we should proceed for now.

[kgryte]

modify library-manifest to gracefully fallback to the "build" task for any dependency that does not satisfy the current conditions (like benchmark or test).

This is not something we should do. library-manifest is a general-purpose package. We should not be elevating any particular task, especially when that task is specific to stdlib.