On Sun, Jun 22, 2008 at 1:05 PM, James Keenan via RT
<[EMAIL PROTECTED]> wrote:
> On Sat Jun 21 07:16:56 2008, [EMAIL PROTECTED] wrote:
> [snip]
>>
>> (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;
>>
>> (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.
>>
>
>
> Please review the patch attached, which represents the current state of
> development in the 'opsrenum' branch in the repository.  The patch
> implements (a), (b) and (c) above.
>
> As for (d), I limited myself to establishing a 'renumberops' target in
> config/gen/makefiles/root.in.  I then reconfigured and called 'make
> renumberops'.  It renumbered the ops, because, after handling
> src/ops/core.ops, it handled the remaining .ops files (including
> experimental.ops but excluding obscure.opc) in alphabetical order.  In
> contrast, the older tools/dev/ops_renum.mak for some reason had stm.ops
> out of alphabetical order.
>
> One thing I don't understand:  In config/gen/makefiles/root.in, I see
> the following variable assignment:
>
>  OPS_FILES = @ops@ $(GEN_OPSFILES)    # line 455
>
> There currently are no generated .ops files (I think):
>
>  GEN_OPSFILES =   # line 210
>
> So OPS_FILES holds @[EMAIL PROTECTED]  But I don't understand where @ops@ is
> defined/assigned to.
>
> This patch passes all existing tests, but since I never used
> tools/dev/ops_renum.mak myself, I can't guarantee that that covers all
> bases/cases.  I would recommend that those who are concerned about this
> RT do a checkout of the 'opsrenum' branch, add/subtract some ops, and
> then see if both tools/dev/opsrenumber.pl and make renumberops DTRT.
>
> Thank you very much.
>
> kid51
>

First, thanks for tackling this. I'd honestly like to incorporate this
target into the normal build chain so we don't have to manually run it
anymore, but eliminating the custom make file is definitely a pre-req
for that.

Second, two notes about the branch:

In a fresh checkout, if I 'make renumberops' with no local
modifications, src/ops/ops.num changes.
If I rename the op store_lex to barf_lex, and run 'make renumberops',
the opcode barf_lex doesn't show up in src/ops/ops.num. (But,
store_lex vanishes)

Regards.

-- 
Will "Coke" Coleda

Reply via email to