parrotcode: Generate Perl module from operation definitions | |
Contents | Tools |
tools/build/ops2pm.pl - Generate Perl module from operation definitions
$ perl tools/build/ops2pm.pl [--help] [--no-lines] input.ops [input2.ops ...]
$ perl tools/build/ops2pm.pl [--renum] input.ops [input2.ops ...]
Reads the ops files listed on the command line and outputs a Parrot::OpLib::core module containing information about the ops. Also outputs include/parrot/oplib/ops.h. This program is called by Parrot's make.
If called with the --renum
flag, checks the numbering of ops against src/opts/opts.num.
--help
--no-lines
#line
directives in the generated C code.--renum
Most of the functionality in this program is now held in Parrot::Ops2pm::Util methods and a small number of Parrot::Ops2pm::Auxiliary subroutines. See those modules' documentation for discussion of those functions. Revisions to the functionality should be made in those packages and tested against tests found in t/tools/ops2pmutils/.
Generating a Parrot::OpLib::core
module for a set of ops files that you do not later turn into C code (see tools/build/ops2c.pl) with the same op content and order is a recipe for disaster. But as long as you just run these tools in the standard build process via make
there shouldn't be a problem.
The original design of the ops processing code was intended to be a read-only representation of what was in a particular ops file. It was not originally intended that it was a mechanism for building a bigger virtual ops file from multiple physical ops files.
This code does half of that job (the other half is getting them to compile together instead of separately in a *_ops.c file).
You can see evidence of this by the way this code reaches in to the internal OPS
hash key to do its concatenation, and the way it twiddles each op's CODE
hash key after that.
If the op and oplib Perl modules are going to be used for modifying information read from ops files in addition to reading it, they should be changed to make the above operations explicitly supported.
Otherwise, the Parrot build and interpreter start-up logic should be modified so that it doesn't need to concatenate separate ops files.
Over the years, tools/build/ops2pm.pl has been worked on by the following Parrot hackers:
bernhard
brentdax
chip
chromatic
coke
dan
gregor
jkeenan
leo
mikescott
particle
paultcochrane
petdance
robert
simon
tewk
Others who provided code cited in the version control logs include:
Andy Dougherty
Jeff Gof
Steve Fink
|