On Sat, Jun 21, 2008 at 1:40 PM, chromatic <[EMAIL PROTECTED]> wrote: > On Saturday 21 June 2008 07:16:58 James Keenan via RT wrote: > >> On Sat May 10 20:22:53 2008, coke wrote: >> > This make file isn't preprocessed like the standard root.in: it >> > assumes perl is in your path, and redefines the list of OPSFILES. >> >> Let me pose some questions: >> >> 1. Who actually uses this program? Under what circumstances? > > Anyone who adds or removes a (non-experimental) Parrot op. > >> 2. Must exist this program as a makefile? > > Not at all. As far as I know, the only reason it's a makefile is history.
I would rather it existed as a build step in the regular makefile. Perhaps something that was only triggered if you were running in --maintainer mode, as I have suggested elsewhere. >> So both tools/dev/ops_renum.mak and ops2pm.pl --renum seem to be Parrot >> developers tools -- not intrinsic components of 'make'. My >> recommendation -- once we have answered question (1) above -- would be: >> >> (a) pull renum_op_map_file() out of Parrot::Ops2pm::Utils and into a >> subclass -- the better to emphasize that it's not part of the regular >> 'make' process; > > I'm not sure a subclass is strictly necessary, but that won't hurt. > >> (b) pull the '--renum' option out of tools/build/ops2pm.pl; >> >> (c) replace tools/dev/ops_renum.mak with a pure Perl program which does >> what 'tools/build/ops2pm.pl --renum' does now; and >> >> (d) only at this point determine whether we need to gussy this up as a >> 'make' target. > > It would be convenient to have a make target which renumbers ops. Every time > I've added or removed an op, I've had to go source diving to figure out where > and how to invoke this makefile. > >> [1] 'make' invokes 'ops2pm.pl' once: >> >> /usr/local/bin/perl tools/build/ops2pm.pl src/ops/core.ops >> src/ops/bit.ops src/ops/cmp.ops src/ops/debug.ops >> src/ops/experimental.ops src/ops/io.ops src/ops/math.ops >> src/ops/object.ops src/ops/pic.ops src/ops/pmc.ops src/ops/set.ops >> src/ops/stm.ops src/ops/string.ops src/ops/sys.ops src/ops/var.ops >> >> core.ops is called first, then all the other .ops files in that >> directory *except* 'obscure.ops' are called in alphabetical order. >> >> tools/dev/ops_renum.mak calls the same list *with the exception of* >> 'experimental.ops.' I am not clear on why 'make' and >> 'tools/dev/ops_renum.mak' call different lists of '.ops' files -- and >> I'm not sure why we retain a file called 'obscure.ops' in the same >> directory as all our other essential '.ops' files. > > None of the ops in experimental.ops get formal op numbers, as far as I can > tell. Thus they don't need renumbering. In ages past, I believe this was setup so that we would have a place we could put ops that would allow us to add and subtract ops without impacting our declared op list in between major releases. > I don't know what, if anything, uses obscure ops. While there is plenty of room for obscure ops in parrot's bytecode, I would recommend that we move these particular ops over to methods on the Float pmc and retire the obscure.ops file; unless nothing uses them, in which case I suggest we just rip them out. > -- c > -- Will "Coke" Coleda
