Hi,
First of all, I would like to thank you for providing this great package. It is very useful when developing perl scripts in an global engineering development environment, especially when the complexity of the script is high and there are many users.
Since my IT installation does not include GetOpt::Declare, I downloaded it to a local area and made custom changes.
Here are my suggestions for improvement (I actually made these changes and have been running with them for some time).
1) Allow 'help' to be present anywhere within the command; not just by itself.
When a script has many arguments and you start typing them on the command line and then you forget one, it's nice to just type -help and hit enter, look at the help, retrieve the last command (with the -help), backspace over the -help and finish entering the arguments.
It seems that Getopt::Declare only allows -help by itself.
2) Allow the parameter description to not be terminated by a blank line when displaying help info.
When the script contains arguments that need detailed explanations, this change allows those explanations to be presented in a more user-friendly readable format.
Here's an example argument:
-replace\t
[required][requires: -dut && -tcf]
Replace the Test Bench components that are specified in the Testbench
Configuration File (see '-tcf' argument below).
This argument causes tb_wizard to replace code between the XTL start tag
and the XTL end tag that corresponds to each XTL Spec name/instance name
pair specified in the Testbench Configuration File.
Care must be taken if you use this argument because if you have manually
modified any code within these XTL tags, then it may potentially be lost.
Only use -replace rather than -reinstall when you 'know' that the
the component does not contain any optimizable code.
You can use -replace to incrementally add components to you testbench, but
remember that it will not optimize out any duplicate code (see -reinstall
above).
-next_parm\t . . .
3) Enhance code to NOT suppress any text in square brackets (just the directives) when displaying help information.
If I have a description such as "my_script required_args [optional_args]" it suppresses the "[optional_args]".
4) Add a new [suppress_usage] directive to suppress displaying of usage info, since it is not accurate and developers may want to provide their own more detailed version. When this directive is enabled, the 'try $ltprogram_name> -help' message is also suppressed.
5) Fix code to recognize an invalid argument when the specified argument has one extra character appended to the end of a valid argument. This occurs when " [cluster:none]" and "[strict]" directives are specified.
For instance, if '-trace' is a valid parameter and '-tracez' was entered', then no error would be flagged.
With my fix below, if '-tracez' is entered, an error message is flagged, although not an appropriate one.
"Error: unrecognizable argument 'z'"
6) Fix code to recognize similar values for custom parameter types.
For instance, when the following lines are defined:
[pvtype: class_type /bus_master|bus_master_container|bus_master_descriptor/]
-class_type <type:class_type$gt
And this lined was entered:
-class_type bus_master_container
The code would match 'bus_master' and not 'bus_master_container' and thus '$parms->{-class_type}' would contain 'bus_master'.
7) Change error message when a parameter requires another parameter.
Original message was:
Error: parameter '-add' can only be specified with '-dut and -instance'
New message is:
Error: parameter '-add' requires '-dut and -instance'
The original message implies that '-add' can only be specified with '-dut and -instance', but in actuality it can be specified with '-foo_bar' too, although '-foo_bar' is optional.
8) Change error message when a parameter is missing its associated value.
Original message was:
Error: incorrect specification of '-add' parameter
New message is:
Error: No value or invalid value specified with '-add' parameter
9) Don't display 'unrecognizable argument' error messages if previous error messages have been encountered or at least have a directive to disable this.
10) Change code to NOT check for unrecognizable arguments when a previous error is encountered, since it would inadvertently recognize valid arguments as unrecognizable.
11) Remove '()' in error message when a parameter is unrecognized.
Original message was:
Error: unrecognizable argument ('-bad')
New message is:
Error: unrecognizable argument '-bad'
Here are the differences (diff) that I made versus version '1.11'.
