starred/json
1
0
Fork 0
mirror of https://github.com/nlohmann/json.git synced 2026-09-27 14:20:19 +01:00
Code Issues Packages Projects Releases 10 Wiki Activity
Files
d3be1bd74dea463aa40df32486a8564698acf062
json/FILES.md
T
Niels Lohmann 305ca7dadd Add missing headers to BUILD.bazel and check it in CI (#5554) 
* Add missing headers to BUILD.bazel and make its generator reproduce it

The "json" cc_library did not list three headers that the library
includes:

- detail/meta/logic.hpp (added in #5016, included by from_json.hpp)
- detail/input/number_parse.hpp (added in #5283, included by lexer.hpp)
- detail/input/string_scan.hpp (added in #5283, included by lexer.hpp
  and serializer.hpp)

Bazel's sandbox only exposes declared headers, so any target depending
on @nlohmann_json//:json and including <nlohmann/json.hpp> failed with
"'nlohmann/detail/meta/logic.hpp' file not found".

The file could not simply be regenerated, because the generator behind
"make BUILD.bazel" was stale: it wrote only the "json" cc_library and
dropped the load() statements, the license block, and the
"singleheader-json" target that were added by hand in #4584. The
generator now emits the complete file, so its output differs from the
previous BUILD.bazel only by the three headers. It also resolves the
glob against the project root instead of the working directory and
sorts the list explicitly.

"make BUILD.bazel" is now phony: in a fresh checkout, BUILD.bazel is
not older than the headers, so make considered it up to date, and a
removed header would never trigger a rebuild. "make check-amalgamation"
also checks that BUILD.bazel is up to date.

Signed-off-by: Niels Lohmann <mail@nlohmann.me>

* Check in CI that BUILD.bazel is up to date

The "Check amalgamation" workflow now also regenerates BUILD.bazel, so a
pull request that adds, renames, or removes a header without updating
the Bazel header list fails, and the attached amalgamation.patch
contains the fix. The failure comment and the contribution guidelines
mention the new check, and the comment now links to the existing
"Amalgamate the source code" section instead of the "Files to change"
anchor that was removed in #4560.

Signed-off-by: Niels Lohmann <mail@nlohmann.me>

---------

Signed-off-by: Niels Lohmann <mail@nlohmann.me>
2026-09-24 17:07:21 +02:00

278 lines
11 KiB
Markdown
Raw Blame History

# Supporting files
This file describes the source for supporting files; that is, files that are not part of the library, but define the infrastructure and other aspects of the project.
- [Continuous Integration](#continuous-integration)
- [GitHub](#github)
- [REUSE](#reuse)
- [Package Managers](#package-managers)
## Continuous Integration
### `.github/workflows`
The [GitHub Actions](https://docs.github.com/en/actions) workflows that build, test, and analyze the library. Each file in this folder defines one workflow:
- `ubuntu.yml`, `macos.yml`, `windows.yml` — build and run the test suite on Linux, macOS, and Windows.
- `check_amalgamation.yml` — verify that the single-header amalgamation in `single_include` is up to date on pull requests.
- `comment_check_amalgamation.yml` — comment on a pull request when the amalgamation check failed.
- `cifuzz.yml` — run short fuzzing sessions via [OSS-Fuzz CIFuzz](https://google.github.io/oss-fuzz/getting-started/continuous-integration/) on pull requests.
- `codeql-analysis.yml` — run [CodeQL](https://codeql.github.com) code scanning.
- `flawfinder.yml` — run the [Flawfinder](https://dwheeler.com/flawfinder/) static analysis.
- `semgrep.yml` — run [Semgrep](https://semgrep.dev) static analysis.
- `scorecards.yml` — run the [OpenSSF Scorecard](https://securityscorecards.dev) supply-chain security checks.
- `dependency-review.yml` — scan dependency changes in pull requests for known vulnerabilities.
- `labeler.yml` — the "Pull Request Labeler" workflow (see `.github/labeler.yml`).
- `stale.yml` — comment on and close stale issues and pull requests.
- `publish_documentation.yml` — build and publish the documentation on every merge to the `develop` branch.
Further documentation:
- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions)
> [!IMPORTANT]
> The folder `.github/workflows` is predetermined by GitHub.
### `.cirrus.yml`
Configuration file for the pipeline at [Cirrus CI](https://cirrus-ci.com/github/nlohmann/json).
Further documentation:
- [Writing tasks](https://cirrus-ci.org/guide/writing-tasks/)
> [!IMPORTANT]
> The filename `.cirrus.yml` and position (root of the repository) are predetermined by Cirrus CI.
### `.github/external_ci/appveyor.yml`
Configuration for the pipelines at [AppVeyor](https://ci.appveyor.com/project/nlohmann/json).
Further documentation:
- [appveyor.yml reference](https://www.appveyor.com/docs/appveyor-yml/)
> [!NOTE]
> The filename can be freely configured in the AppVeyor project.
## GitHub
### `CITATION.cff`
A file to configure the citation for the repository which is displayed in the sidebar of the project.
Further documentation:
- [About CITATION files](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-citation-files)
> [!IMPORTANT]
> The filename `CITATION.cff` and position (root of the repository) are predetermined by GitHub.
### `.github/CODE_OF_CONDUCT.md`
The code of conduct for the project. This is the Markdown version of the [Contributor Covenant Code of Conduct](https://www.contributor-covenant.org/version/2/1/code_of_conduct/). The code of conduct is linked on the [Community Standards](https://github.com/nlohmann/json/community) page and is mentioned by the Sentiment Bot.
Further documentation:
- [Adding a code of conduct to your project](https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/adding-a-code-of-conduct-to-your-project)
> [!IMPORTANT]
> The filename `.github/CODE_OF_CONDUCT.md` is predetermined by GitHub.
> [!NOTE]
> The file is part of the documentation and is included in `docs/mkdocs/docs/community/code_of_conduct.md`.
### `.github/CODEOWNERS`
The code owners file for the project which is used to select reviewers for new pull requests.
Further documentation:
- [About code owners](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners)
> [!IMPORTANT]
> The filename `.github/CODEOWNERS` is predetermined by GitHub.
### `.github/config.yml`
Configuration file for [probot](https://probot.github.io/apps/), in particular the [Sentiment Bot](https://probot.github.io/apps/sentiment-bot/) and the [Request Info](https://probot.github.io/apps/request-info/).
> [!IMPORTANT]
> The filename `.github/config.yml` is predetermined by probot.
### `.github/CONTRIBUTING.md`
The contribution guidelines which are linked in the [Community Standards](https://github.com/nlohmann/json/community) and at <https://github.com/nlohmann/json/contribute>.
Further documentation:
- [Setting guidelines for repository contributors](https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)
> [!IMPORTANT]
> The filename `.github/CONTRIBUTING.md` is predetermined by GitHub.
> [!NOTE]
> The file is part of the documentation and is included in `docs/mkdocs/docs/community/contribution_guidelines.md`.
### `.github/dependabot.yml`
The configuration of [dependabot](https://github.com/dependabot) which ensures the dependencies (GitHub actions and Python packages used in the CI) remain up to date.
Further documentation:
- [Configuring Dependabot security updates](https://docs.github.com/en/code-security/dependabot/dependabot-security-updates/configuring-dependabot-security-updates)
> [!IMPORTANT]
> The filename `.github/dependabot.yml` is predetermined by GitHub.
### `.github/FUNDING.yml`
A file to configure the sponsor button of the repository which is displayed in the sidebar of the project.
Further documentation:
- [Displaying a sponsor button in your repository](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/displaying-a-sponsor-button-in-your-repository)
> [!IMPORTANT]
> The filename `.github/FUNDING.yml` is predetermined by GitHub.
### `.github/ISSUE_TEMPLATE/bug.yaml`
Issue form template for bugs.
Further documentation:
- [Configuring issue templates for your repository](https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository)
> [!IMPORTANT]
> The folder `.github/ISSUE_TEMPLATE` is predetermined by GitHub.
### `.github/ISSUE_TEMPLATE/config.yml`
Issue template chooser configuration. The file is used to configure the dialog when a new issue is created.
Further documentation:
- [Configuring issue templates for your repository](https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository)
> [!IMPORTANT]
> The filename `.github/ISSUE_TEMPLATE/config.yml` is predetermined by GitHub.
### `.github/labeler.yml`
Configuration file for the "Pull Request Labeler" workflow defined in `workflows/labeler.yml`. This file defines rules how labels are assigned to pull requests based on which files are changed.
Further documentation:
- [Label manager for PRs and issues based on configurable conditions](https://github.com/srvaroa/labeler)
> [!NOTE]
> The filename defaults to `.github/labeler.yml` and can be configured in the workflow.
### `.github/PULL_REQUEST_TEMPLATE.md`
The pull request template which prefills new pull requests.
Further documentation:
- [Creating a pull request template for your repository](https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository)
> [!IMPORTANT]
> The filename `.github/PULL_REQUEST_TEMPLATE.md` is predetermined by GitHub.
### `.github/SECURITY.md`
The goal is to describe how to securely report security vulnerabilities for this repository. The security policy is linked at <https://github.com/nlohmann/json/security/policy>.
Further documentation:
- [Adding a security policy to your repository](https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository)
> [!IMPORTANT]
> The filename `.github/SECURITY.md` is predetermined by GitHub.
> [!NOTE]
> The file is part of the documentation and is included in `docs/mkdocs/docs/community/security_policy.md`.
### `LICENSE.MIT`
The license of the project.
Further documentation:
- [Adding a license to a repository](https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/adding-a-license-to-a-repository)
> [!IMPORTANT]
> The filename `LICENSE.MIT` is partly predetermined by GitHub. The root filename must be `LICENSE`.
## REUSE
### `.reuse/dep5`
The file defines the licenses of certain third-party components in the repository. The root `Makefile` contains a target `reuse` that checks for compliance.
Further documentation:
- [DEP5](https://reuse.software/spec-3.2/#dep5-deprecated)
- [reuse command-line tool](https://pypi.org/project/reuse/)
- [documentation of linting](https://reuse.readthedocs.io/en/stable/man/reuse-lint.html)
- [REUSE](http://reuse.software)
> [!IMPORTANT]
> The filename `.reuse/dep5` is predetermined by REUSE. Alternatively, a `REUSE.toml` file can be used.
### `.reuse/templates`
Copyright header templates for source files. The root `Makefile` contains a target `reuse` that updates copyright headers with the templates.
Further information:
- [reuse command-line tool](https://pypi.org/project/reuse/)
- [documentation on templates](https://reuse.readthedocs.io/en/stable/man/reuse-annotate.html#cmdoption-t)
- [REUSE](http://reuse.software)
> [!IMPORTANT]
> The folder name `.reuse/templates` is predetermined by REUSE.
### `LICENSES`
A folder that contains every license of all license files (library and third-party code).
Further documentation:
- [REUSE specification](https://reuse.software/spec-3.3/)
> [!IMPORTANT]
> The folder name `LICENSES` is predetermined by REUSE.
## Package Managers
### `BUILD.bazel`
The build definition for [Bazel](https://bazel.build). The file is generated by
`cmake/scripts/gen_bazel_build_file.cmake`, which derives the header list from the files in `include`; change the
script rather than editing the file by hand. The file can be updated by calling
```shell
make BUILD.bazel
```
The "Check amalgamation" workflow fails if the file is out of date.
### `meson.build`
The build definition for the [Meson](https://mesonbuild.com) build system.
### `Package.swift`
The package manifest for the [Swift Package Manager](https://www.swift.org/package-manager/).
### `MODULE.bazel`
The module definition for [Bazel](https://bazel.build)'s [Bzlmod](https://bazel.build/external/module) dependency system. It complements `BUILD.bazel` and replaces the previously used `WORKSPACE.bazel`.
Further documentation:
- [Bazel modules](https://bazel.build/external/module)
Reference in New Issue View Git Blame Copy Permalink