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. > 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. I don't know what, if anything, uses obscure ops. -- c
