So, while we're having a little freeze, some
thoughts/proposals:
We've seen at least 2 implementations of the
build_interp_starter/process_opfunc stuff.
Lets consider how we can structure this code
with the Parrot/*.pm stuff to be as generic
and flexible as we can ( for a very targetted
purpose, admitted ).
We know that we are generating a few files, and
may very well end up wanting to do others, so
let's factor that possiblity in. Perhaps a general
system of
Read a template or existing .c/.h file
Process the stream
Write out a new file/Modify the old one
Insofar as things like "We're on an arch where
we want to use switch instead of function pointers..."
is something that Configure would put into
the Makefile, I rather like Damien's notion of
a unified driver script that takes a command-line
option to make decisions, as this would be easy for
Configure to handle.
Shall we consider removing stuff like C comments
and CPP directives from basic_opcodes.ops, as it
is a template which will be processed with different
ends in mind, and let the processor script decide
what needs to be in the output? Implied similar
approach to other template-type files we may use
in the future.
Overall, I think it would be good to get a _structure_
for all of these related operations with which we can
fill in the details later.
Cheers.
Michael
--
Michael Fischer 7.5 million years to run
[EMAIL PROTECTED] printf "%d", 0x2a;
-- deep thought
