Clone wiki

Command Line Parser Generator / Home

The tool

Takes a package specification, and generates a driver program for calling all the procedures declared in the public part of the package.

Which procedure is called depends only on the command line arguments passed to the driver program. The selection happens by matching names and (apparent) types of command line arguments with names and types of formal parameters of the procedures.

An imagined example:

   package An_Application is
      procedure Show_Help (Help : Boolean);
      procedure Run_Interactive;
   end An_Application;

If the generated driver is executed with a single command line argument --help=true (or --help), An_Application.Show_Help should be called. If the driver is executed without any command line arguments, An_Application.Run_Interactive should be called. Otherwise the driver should terminate with an appropriate error message.

As command line arguments technically always are strings, it is possible to have some impractical situations, but I hope to find a sensible way to detect this kind of formal parameter "overloading".

Using the tool:

If you want to process sources from other/more directories than just the one you are running the tool from, you should set the environment variable ADA_INCLUDE_PATH to list all the relevant directories (separated by :).

You run the tool to generate a driver for An_Application like this:

command_line_parser_generator-run An_Application

It will create a directory named generated/ and put the generated driver sources there. The main program will be called An_Application.Driver and be stored in the file generated/an_application-driver.adb.

Building the tool:


OS_VERSION=unix make

in the root directory of the checked out repository builds the tool in the bin/ directory. Copy the executable to a directory on your path.

Steps on the way...

Next steps:

  • A list of the procedures declared in the public part of the package specification. Including a list of the formal parameters for each procedure containing:
    • The name of the formal parameter.
    • The functions to call for converting the formal parameter type to and from type String. (If the type has Image and Value as primitive operations, they are preferred, as a secondary option 'Image and 'Value attributes are used. If neither exists, the type can not be used.)
    • The default value of the formal parameter (if any).
    • The type of the formal parameter (for generating a useful help/error message).

The tool is only going to run on "development hosts", so (as a first approximation) memory and CPU usage does not matter.

It seems likely that the requirements may change in the future. I've already had comments about parsing comments/aspects as help text for the generated driver.