AdaCore / AdaCore/gnatdoc

Add support for GNATdoc command-line options in GPR project files

Open
#33 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Ada
Stars
6
Forks
4
PR merge metrics
No merged PRs in 30d

Description

Add support for GNATdoc command-line options in GPR project files

Summary

Currently, GNATdoc requires users to specify various options through command-line arguments. It would be beneficial to support these options directly within GPR project files to improve project configuration management and reproducibility.

Current Situation

GNATdoc supports numerous command-line options such as:

  • --output-dir for specifying output directory
  • --backend for selecting output format (HTML/RST)
  • --generate for selecting entity visibility level
  • --style for documentation comment style
  • --warnings for enabling missing documentation warnings
  • Various other options for project configuration

Based on the documentation, there is already partial support for GPR project file configuration:

  • Documentation'Output_Dir attribute is supported (as mentioned in the --output-dir option description)

However, most other options must still be specified each time GNATdoc is invoked, making it difficult to maintain consistent documentation generation across team members and CI/CD pipelines.

Proposed Enhancement

Expand the existing GPR project file support to include all major GNATdoc command-line options. Currently, only Documentation'Output_Dir is documented as supported. The enhancement would add support for attributes such as:

project My_Project is
   package Documentation is
      for Output_Dir use "docs";                    -- Already supported
      for Backend use "html";                       -- New: html, rst
      for Generate use "public";                    -- New: public, private, body
      for Style use "gnat";                         -- New: leading, trailing, gnat
      for Warnings use "true";                      -- New: enable warnings
      for Verbose use "false";                      -- New: enable verbose output
   end Documentation;
end My_Project;

Benefits

  1. Consistency: All team members use the same documentation generation settings
  2. Maintainability: Configuration is version-controlled alongside the project
  3. CI/CD Integration: Simplified automation without complex command-line argument management
  4. Project Self-Documentation: Documentation settings are visible in the project structure

Alternative

If more GPR attributes are already supported beyond Documentation'Output_Dir, please update the documentation to clearly describe:

  • Complete list of available GPR attributes for GNATdoc configuration
  • Examples of common use cases for each attribute
  • How GPR settings interact with command-line options (precedence rules)
  • Valid values for each attribute (e.g., backend options, generate options, style options)

The current documentation only mentions Documentation'Output_Dir but doesn't provide a comprehensive reference for project-level GNATdoc configuration.

Real-world Use Case

In my current workflow, I use VS Code with the Ada extension for development. The IDE's hover functionality appears to use either GNAT or trailing style for extracting documentation comments, but my project uses leading style comments (documentation before entity declarations). This mismatch causes the IDE to display incorrect or missing documentation when hovering over elements like packages.

Having the ability to specify for Style use "leading"; in the GPR file would allow the Ada toolchain (including IDE integrations) to consistently use the correct documentation style across all tools, ensuring that:

  • GNATdoc generates proper documentation
  • IDE hover tooltips show the correct comments
  • All team members see consistent documentation regardless of their tooling

This highlights the importance of project-level configuration for documentation settings, as different projects may legitimately use different documentation styles, and all tools should respect the project's chosen convention.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No source files or tests are identified in the issue. Start by locating the existing handling of the Documentation'Output_Dir GPR attribute and the GNATdoc command-line options; define the supported attributes, valid values, and command-line precedence before implementing and documenting the project-file configuration.

Written by the indexing model from the issue text.

Assessment

Domain
documentation, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.