NotImplementedError: Documentation cannot be generated for:

[dschiller]

Describe the bug Doc generation fails.

To Reproduce Steps to reproduce the behavior:

1. Create doc string like

   #[[[
   # Text
   #]]
   add_library(
   ...
   )

2. Generate
3. See error

   Traceback (most recent call last):
   File "main.py", line 27, in <module>
   File "cminx/__init__.py", line 70, in main
   File "cminx/__init__.py", line 120, in document
   File "cminx/__init__.py", line 158, in document_single_file
   File "cminx/documenter.py", line 71, in __init__
   File "antlr4/tree/Tree.py", line 151, in walk
   File "antlr4/tree/Tree.py", line 149, in walk
   File "antlr4/tree/Tree.py", line 163, in enterRule
   File "cminx/parser/CMakeParser.py", line 264, in enterRule
   File "cminx/parser/aggregator.py", line 190, in enterDocumented_command
   NotImplementedError: Documentation cannot be generated for:
   #[[[
   # Text
   #]]
   add_library(...)
   [18143] Failed to execute script main

   Expected behavior Should generate docs

Additional context Maybe add_library can not have docstrings

[AutonomicPerfectionist]

We currently only support documenting function(), macro(), set(), ct_add_test(), and ct_add_section(). We can certainly add such functionality, however I am unsure how it should be presented in the generated RST. @ryanmrichard do you have any ideas on which directives we should use for that? Perhaps a variable directive plus an admonition specifying it's a library?

[ryanmrichard]

It's really documenting how an existing function is being called. The way we document functions implies that we're documenting the definition of the function, not an invocation; so that's probably not the way to go. It's not a variable, so that doesn't right either.

How do we document ct_add_test? Maybe take that functionality and make it general for documenting any function call?

On Fri, Jan 14, 2022, 8:24 AM Branden Butler @.***> wrote:

We currently only support documenting function(), set(), and ct_add_test(). We can certainly add such functionality, however I am unsure how it should be presented in the generated RST. @ryanmrichard https://github.com/ryanmrichard do you have any ideas on which directives we should use for that? Perhaps a variable directive plus an admonition specifying it's a library?

— Reply to this email directly, view it on GitHub https://github.com/CMakePP/CMinx/issues/51#issuecomment-1013160341, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIJDC76GFT7467B5YOHKNDUWAW3HANCNFSM5L56CZLQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[AutonomicPerfectionist]

ct_add_test() is being documented like a function but with an admonition that it's a test. It would be fairly simple to add processing for all documented commands (just replace the raise NotImplementedError() with process_general_function() or whatever), I'm just not sure what RST to generate for them, since Sphinx has no analog for documenting general function calls. I suggested the variable directive since add_library() behaves kinda like setting a global variable and it was the closest Sphinx directive I could think of.

[ryanmrichard]

Gotcha. So maybe the question is for @dschiller then; what do you want it to do?

[ryanmrichard]

@AutonomicPerfectionist to circle back to this, I vote we do the ct_add_test route and generalize it so that the admonition is the something like invocation of <name of the function>