art service/module command-line helpers
There are a few command-line invocations that would be very helpful for art users.
1. Listing available modules and services
A snapshot of a user's art environment could be quickly gleaned if the following were supported:
art --print-available-modules art --print-available-services
I envisage a printout that lists all modules/services that a user can specify in his/her FHiCL file. A sample printout might look like:
$ art --print-available-modules Module Description ==================================================================== mod1 First module that can be invoked in a FHiCL file mod2 Some module that does some fun physics mod3 [[ no description provided ]]
The description is something that is provided by the author of the module, probably defined as a static member function.
2. Listing available module/service location
For those modules/services that are available, a user should be able to do:
art --print-module-location mod1 mod2 ...
with a printout like:
Module Location ==================================================================== mod1 /some/abs/dir/to/mod1_module.cc mod2 /some/other/abs/dir/to/mod2_module.cc
This information could be included in the printout in 1, but the formatting might get sticky because of the description.
3. Listing per-module/-service configuration options
This feature, along with the "description" in 1, may be the trickiest part, requiring effort on the part of the module/service authors. It would be helpful for users if they were able to print out:
- supported FHiCL parameters (and a description of them) for a given module or service, and
- a sample FHiCL file that can be used for a given module.
Such invocations could be:
art --print-fhicl-options mod1 art --print-fhicl-file mod1
I have started to produce some prototype code that does step 3, but this intimately related to art's intentions for a static analyzer, and issue #4107.
#1 Updated by Kyle Knoepfel over 5 years ago
- Status changed from New to Feedback
We will discuss this at an upcoming stakeholders meeting to get user input and help prioritize.
- We would combine 1 and 2
- Possible implementation of the description might involve an extended definition macro for the module/service.