Summary
The harp.schemaprocessor tool in the main harp-tech website generates register tables for devices in the API documentation (e.g. Harp.Behavior Registers). It works by processing individual device.yml in harp device repositories that were imported as submodules.
With the move to a new standardized device repository layout with self-hosted documentation (e.g. harp-tech/device.behavior#39), we should figure out if we want to keep this tool/feature for the individual device documentation, and how to package the tool.
Proposal
Place harp.schemaprocessor in harp.toolkit and call it as part of the documentation build step in the CI/CD pipeline.
Drawbacks
It expands the scope of harp.toolkit as harp.toolkit will now be involved in documentation generation as well.
Alternatives
We could include it in the harp fork of docfx-tools. It is probably the more intuitive location as a documentation helper. However, we would be bundling the source, building it, and running it as a dotnet project, which is different from how the other assets in there are used currently. If we don't mind expanding the scope of harp.toolkit, I still prefer including it with that.
Summary
The harp.schemaprocessor tool in the main harp-tech website generates register tables for devices in the API documentation (e.g. Harp.Behavior Registers). It works by processing individual
device.ymlin harp device repositories that were imported as submodules.With the move to a new standardized device repository layout with self-hosted documentation (e.g. harp-tech/device.behavior#39), we should figure out if we want to keep this tool/feature for the individual device documentation, and how to package the tool.
Proposal
Place
harp.schemaprocessorinharp.toolkitand call it as part of the documentation build step in the CI/CD pipeline.Drawbacks
It expands the scope of
harp.toolkitasharp.toolkitwill now be involved in documentation generation as well.Alternatives
We could include it in the harp fork of docfx-tools. It is probably the more intuitive location as a documentation helper. However, we would be bundling the source, building it, and running it as a dotnet project, which is different from how the other assets in there are used currently. If we don't mind expanding the scope of
harp.toolkit, I still prefer including it with that.