---

popt2amplkwd.hh File Reference

Converts options as understood by popt (a free options parser used by the RedHat package manager) into the format understood by AMPL. More...

Go to the source code of this file.

---

Detailed Description

Converts options as understood by popt (a free options parser used by the RedHat package manager) into the format understood by AMPL.

There is not a 1-1 mapping between these formats, but we can do a fair job. See the section on typical usage.

A long option of the form

solver --optionName=argument

converted to an AMPL keyword of the form

solver stub.nl optionname=argument

Short options are ignored. Furthermore, due to AMPL restrictions all keywords are downcased.

The popt option structure is struct poptOption { const char * longName; char shortName; int argInfo; void * arg; int val; char * descrip; char * argDescrip; };

The name of the option is given in "longName". The downcase of this is the AMPL keyword. As stated above "shortName" is ignored. The field "argInfo" is the type of option. The types that popt2ampkwd understands are

Value Description arg Type POPT_ARG_NONE No argument expected int POPT_ARG_STRING No type checking to be performed char * POPT_ARG_INT An integer argument is expected int POPT_ARG_LONG A long integer is expected long POPT_ARG_DOUBLE A double argument is expected double

If any of these types is given, and if arg is not nil, the command line keyword, if present, will be parsed by APML and *arg will be set to a value of the appropriate type. Keywords derived from options of type POPT_ARG_NONE are understood to require an integer arguments. For example, the --quiet option, which doesn't typically require a argument, is translated as follows. The popt syntax

solver --quiet

becomes the AMPL syntax

solver stub.nl quiet=1

where any nonzero value indicates that the switch is on, but 0 or the absence of the keyword indicates that it is off. The field "val" is ignored, because it has no counterpart in AMPL. The fields "descrip" and "argDescrip", on the other hand, are used to generate help messages from AMPL.

In the case in which

• argInfo does not take one of the values listed above;
• arg is nil; or
• longName has the special value "iotr-option"

the responsibility for parsing the argument will be passed to a user defined function. The arguments and behavior of this function are defined in the "Hooking your solver to AMPL" document which may be obtained from the distributors of AMPL. We recommend, however, that the user allow the function "amplfunctional_process_keyword" parse these types of argument. This function is declared (and documented) in AmplFunctional.hh.

Limitations:

• We don't (yet) parse included tables (see the popt documentation.)
• We don't support popt aliases, since they have no counterpart in AMPL.
• POPT_AUTOHELP is unsupported, since this is handled by a different mechanism in AMPL.

The big picture:

The function "popt2amplkwd" is meant to be used in conjuction with an AmplFunctional to parse command line arguments. For the sake of consistency with other iotr executables, we prefer to use a popt structure to specify the arguments, rather than an AMPL keyword structure. On the other hand, we don't want AmplFunctional to depend on the popt package, an so we have not included "popt2amplkwd", or any references to popt data structures, in AmplFuctional.cc or AmplFunctional.hh.

Typical usage is as follows:

poptOption opts[] = { ... }; // several options keyword * kw; int nkw; popt2amplkwd( opts, kw, nkw, amplfunctional_process_keyword ); AmplFunctional * func = new AmplFunctional( "iotr", "iotr" ); IotrConfiguration * commandLineArgs = func->initialize( argv, err, kw, nkw ) ); // All keywords handled by amplfunctional_process_keyword were returned // in commandLineArgs delete_keywords( kw, nkw );

---