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
be called. If the driver is executed without any command line
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:
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
Building the tool:
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...
- 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
Valueas primitive operations, they are preferred, as a secondary option
'Valueattributes are used. If neither exists, the type can not be used.)
- The functions to call for converting the formal parameter type to and from type String. (If the type has
- 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.