Closed Rangi42 closed 4 months ago
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.
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.
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 outputd9640000ff4bca00000000000000000000000000000000000000000000000000
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 thesrc/*.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 printsd9640000ff4bca00000000000000000021042104210421042104210421042104
and my libbet.gb ROM hash ends up being7090c4a8eab6397fdf622cd8e26ba2b0a4ed9ece
. 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:
$(wildcard src/*.z80)
to$(sort $(wildcard src/*.z80))
: Certain versions of GNU Make did not sortwildcard
results, and their order influences the exact placement of variables.palette = im.getpalette()[:48]
topalette = im.getpalette()[:12]
: This keeps just the four known-good colors, and lets the subsequentpalette.extend(bytes(48 - len(palette)))
line pad the extra zeros.nc = len(im.getcolors())
and thenpalette = 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.)