7

I am working on the Blueprint package, a graphical toolkit for project managers and system designers, and time has come to tidy up the library design.

There is several modules in the library and I would like to let each module ensure that its prerequisite definitions are loaded. For instance, module milestonesdiagram requires module reveal and should issue a warning and the former should issue an error message and terminate METAPOST if the latter has not been loaded.

What is the best way to achieve this? I am considering defining version information in each module, but:

  1. This does not work for external libraries not sticking to this convention.
  2. The verification of the version information should really be shared between libraries.
Michaël Le Barbier
  • 1,700

1 Answers1

4

Convention is for each module to prevent itself from being interpreted multiple times using a guard at the top of the module. User code and other modules load external modules as required.

A guard can be implemented by declaring a variable or macro and then testing for its existence using the known operator. If it exists before it has been declared, the module has already been read and code interpretation is stopped via endinput. Here's an example guard:

if known my_module:
  message "module my_module loaded twice";
  expandafter endinput
fi
string my_module;
my_module := "";
message "module my_module loaded once";

<module code>

endinput

Within the if clause, expandafter postpones the effect of endinput just a little to give MetaPost a chance to see the closing fi statement. Otherwise, MetaPost would complain about an open if clause whenever the module is read more than once.

Regarding version management, there's not much support for that in MetaPost. Providing means to retrieve the version number in each module is all you can do, so users can check module version after inputting a module.

For external modules that don't provide version information, you can check for the existence of a particular feature (a variable or macro) using the known operator as shown above. But that won't help with identifying a particular patch level of a module (with certain bugs fixed). If fine grained version information is needed, one option is to contact the module author and make a feature request.

Stephan Hennig
  • 1,151