Document --kind-type in ccpp_capgen.py CLI/help, and consider reversing the syntax for external kind modules
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 25
- Forks
- 67
- Avg merge
- 3d 8h
- Merged PRs (30d)
- 2
Description
Description
The --kind-type argument for capgen accepts kind values that are defined in iso_fortran_env, and it also accepts kind_values that are defined in files provided by the user. The latter syntax, however, isn't documented.
The current syntax is, for example
--kind-type kind_phys=kind_r8:my_host_kinds
and
--kind-type kind_phys=real64
for which the code checks `iso_fortran_env.
I am suggesting to reverse the syntax to
--kind-type NAME=[MODULE:]SPEC
to match my suggestion for external ddts in #751 and because it is more intuitive given the corresponding Fortran code:
use my_host_kinds, only: kind_r8
In addition, there is also this metadata attribute that uses MODULE:SPEC in this order:
[ccpp-table-properties]
name = temp_set
type = scheme
source_path = source_dir2
kind_spec = temp_kinds:kind_temp=>temp_r8
dependencies = temp_kinds.F90
dependencies_path = adjust
Not sure whether anyone is using this syntax, though.
Solution
See above
Alternatives (optional)
Don't change the syntax, but update the CLI/capgen help.
Related to (optional)
#751
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in ccpp_capgen.py by locating the --kind-type argument and its CLI/help text, then compare the documented examples with the current external kind-module syntax. Review the related #751 discussion and the kind_spec metadata example before deciding whether to document the existing form or reverse it. Done means the chosen syntax is consistently documented and the help text matches the behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- fortran, python
- Domain
- cli, documentation
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100