Build is not deterministic

[Rangi42]

RGBDS now verifies that libbet.gb matches the expected ROM hash. All of our CI builds produce the same 8bf954a61cd31fa665ad0abb7cea14561919a12c SHA-1 hash for libbet.gb, and output d9640000ff4bca00000000000000000000000000000000000000000000000000 as the SGB border palette from tools/makeborder.py.

(Note that we're patching it beforehand, partly to not use the 0.7.0-deprecated -h flag which master removes, but also to process the src/*.z80 files in a consistent sorted order.)

The problem is, my system uses Pillow version 9, not 10 like GitHub Actions does. This gives different data from Image.getcolors(), with extra garbage after the four real colors; so tools/makeborder.py prints d9640000ff4bca00000000000000000021042104210421042104210421042104 and my libbet.gb ROM hash ends up being 7090c4a8eab6397fdf622cd8e26ba2b0a4ed9ece. This technically causes the RGBDS test script to fail.

I think a reproducible build would be a useful feature for libbet, so that you and other users could verify if they built it correctly.

The steps to do that are in RGBDS's test/patches/libbet.patch:

• In the Makefile, change $(wildcard src/*.z80) to $(sort $(wildcard src/*.z80)): Certain versions of GNU Make did not sort wildcard results, and their order influences the exact placement of variables.
• In tools/makeborder.py, change palette = im.getpalette()[:48] to palette = im.getpalette()[:12]: This keeps just the four known-good colors, and lets the subsequent palette.extend(bytes(48 - len(palette))) line pad the extra zeros.
  • Alternatively, do nc = len(im.getcolors()) and then palette = im.getpalette()[:nc * 3]. This would work even if tilesets/sgbborder.png is changed to have a different number of colors. (It currently has 4, but could have anywhere from 1 to 16.)

[pinobatch]

Is a deterministic build an ideal that all Game Boy projects' maintainers ought to aspire to as a matter of course? Or only those projects included in a toolchain's test suite? I ask in order to determine whether I ought to make the makefile all deterministic all the time or provide a flag to switch the build among default, deterministic, or randomized modes. I had previously used randomization in Concentration Room for NES for two reasons: to detect buffer overflows faster and to make variables and subroutines appear in a different order in each ROM that I would send out to testers.

[Rangi42]

That's up to you. Personally I'd expect any build variation to be intentional, not happenstance based on your tooling versions. Both things this issue mentions are related to old Make and Pillow versions; if your system is up-to-date your Libbet builds would be deterministic already anyway.