feat: add C and fortran implmentation of blas/base/dgemm

[DhruvArvindSingh]

---

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: passed
• task: lint_package_json status: na
• task: lint_repl_help status: na
• task: lint_javascript_src status: passed
• task: lint_javascript_cli status: na
• task: lint_javascript_examples status: na
• task: lint_javascript_tests status: passed
• task: lint_javascript_benchmarks status: passed
• task: lint_python status: na
• task: lint_r status: na
• task: lint_c_src status: missing_dependencies
• task: lint_c_examples status: missing_dependencies
• task: lint_c_benchmarks status: missing_dependencies
• 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 ---

Progresses #2039 .

Description

What is the purpose of this pull request?

This pull request:

• This PR adds C, CBLAS and Fortran implmentation of blas/base/dgemm along with tests and benchmarks.

Related Issues

Does this pull request have any related issues?

This pull request has the following related issues:

• [RFC]: Add BLAS bindings and implementations for linear algebra (tracking issue) #2039

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

If you answered "yes" above, how did you use AI assistance?

• Code generation (e.g., when writing an implementation or fixing a bug)
• Test/benchmark generation
• Documentation (including examples)
• Research and understanding

Disclosure

If you answered "yes" to using AI assistance, please provide a short disclosure indicating how you used AI assistance. This helps reviewers determine how much scrutiny to apply when reviewing your contribution. Example disclosures: "This PR was written primarily by Claude Code." or "I consulted ChatGPT to understand the codebase, but the proposed changes were fully authored manually by myself.".

{{TODO: add disclosure if applicable}}

---

@stdlib-js/reviewers

[stdlib-bot]

Coverage Report

Package	Statements	Branches	Functions	Lines
blas/base/dgemm	$\color{green}1102/1102$ $\color{green}+0.00%$	$\color{green}170/170$ $\color{green}+0.00%$	$\color{green}10/10$ $\color{green}+0.00%$	$\color{green}1102/1102$ $\color{green}+0.00%$

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

[DhruvArvindSingh]

Hey @kgryte , so i implemented this by taking reference from the blas/base/dger implmentation, it is working as it is supposed to, i just had to do a minor change where i had to add the fortran xerbla(dependecies) path in the MakeFile of fortran benchmark, which i noticed was an issue in the dger package also so i raised a PR for that

[kgryte]

@DhruvArvindSingh As in the dger PR, we don't want to be manually adding relative file paths to the Makefiles, when those files exist outside of the package. That is brittle. What happens if we move the dgemm or xerbla package to a different level in the package tree (e.g., blas/base/utils/xerbla)? Well, we won't we able to immediately track down that we will have broken the benchmarks of dgemm because folks doing package migrations are very unlikely to check for relative paths. Instead, they are going to look for @stdlib/blas/base/xerbla. In general, packages should not be reaching into the file trees of other packages. That is precisely why we came up with a C/Fortran package management system. So, again, the problem resides in how we are resolving and compiling Fortran dependencies.

[DhruvArvindSingh]

Hey @kgryte i have fixed the fortran build issue by doing the following :

1. dgemm/benchmark/fortran/Makefile - Removed the hardcoded xerbla path from SOURCE_FILES, leaving only ../../src/dgemm.f. The script now handle transitive dependencies automatically.

2. tools/scripts/compile_fortran_benchmark - Added a new resolve_source_files() function that reads the package's manifest.json build task (not the benchmark task) via @stdlib/utils/library-manifest, then filters for only .f files. This resolves Fortran source files including transitive dependencies like xerbla dynamically at compile time without any hardcoded paths.

The compile() function was also simplified: it now always passes SOURCE_FILES to make (the conditional branch was removed), and main() calls resolve_source_files to populate source_files when none were provided on the command line.