Oops, I forgot that -custom always builds a runtime, even if not needed. This is still technically "custom"-runtime, but not using -custom, since that will call the linker with whatever boot/ocamlc was configured with.

I agree we have a problem, but I don't think -custom is the solution. It's a bit of a hack and I would very much like to keep it out of the bootstrap path.

I see in the toplevel Makefile that make_opcodes is run with runtime/ocamlrun. Bootstrap-wise, it would work better with boot/ocamlrun, provided that the tools is not built with -use-prims $(ROOTDIR)/runtime/primitives (see tools/Makefile).

I think we need to check tools/ w.r.t. bootstrapping and understand what we want first.

Also: insert my standard rant about using OCaml too early while building OCaml. We keep running into this mistake like a moth keeps flying into a bright light.

I agree we have a problem, but I don't think -custom is the solution. It's a bit of a hack and I would very much like to keep it out of the bootstrap path.

I see in the toplevel Makefile that make_opcodes is run with runtime/ocamlrun. Bootstrap-wise, it would work better with boot/ocamlrun, provided that the tools is not built with -use-prims $(ROOTDIR)/runtime/primitives (see tools/Makefile).

I think we need to check tools/ w.r.t. bootstrapping and understand what we want first.

I did some other poking around before settling on -custom. If we compile tools/make_opcodes without -use-prims and switch over to running it with boot/ocamlrun, we need to do something different at the first partialclean in coreboot which at present erases tools/make_opcodes. We just did promote-cross, so that means we end up building tools/make_opcodes for the new runtime but then try to run it on the old runtime which is still in boot/ocamlrun. It works for me, I just considered it was more invasive than using the cat trick for ocamlrun.

Also: insert my standard rant about using OCaml too early while building OCaml. We keep running into this mistake like a moth keeps flying into a bright light.

I agree, although let's not forget the amount of fighting we also do with sed and awk! Another option, a la #1078, might be to add the script as an option in boot/ocamlc?

let's not forget the amount of fighting we also do with sed and awk

We're in 2021 and there are better scripting languages widely available and used. E.g. Python.

Maybe we could decide that the problem is not worth solving. Do we really need to remove opcodes from the list? Let's just turn them into NOPs and declare them unused/reserved/deprecated/whatever.

For this particular instance that wouldn't work, because the aim was to bring the opcode values back into line with trunk. It seems safe to assume that it won't happen often, but that it'll never happen again - in this case, documenting it almost seems more long-winded than fixing it?

My understanding is that people agree that there is a problem worth solving (at least I would agree), but the specific solution proposed in this PR has been clearly vetoed: no -custom in the bootstrap path.

I'm feeling bold today on my closing-PR-spree, so let me just close this. @dra27, please of course feel free to revisit with another option (you mentioned obscure changes to coreboot, or alternatively embedding more logic in ocamlc), to keep discussing them here if useful, and to reopen if that was a bit too bold.