rgbds-0.6.0 - pb12: BootROMs/pb12.c:90: main: Assertion `outctl != 1' failed.

[orbea]

OS: Gentoo
rgbds: 0.6.0 (https://github.com/gbdev/rgbds/releases/tag/v0.6.0)
SameBoy: 5550727

The recent rgbds v0.6.0 release breaks the SameBoy pb12.c build.

SameBoy/build/pb12 < build/obj/BootROMs/SameBoyLogo.2bpp > build/obj/BootROMs/SameBoyLogo.pb12
pb12: BootROMs/pb12.c:90: main: Assertion `outctl != 1' failed.
Aborted 
make: *** [Makefile:473: build/obj/BootROMs/SameBoyLogo.pb12] Error 134

[LIJI32]

This looks strictly related to pb12 itself and not RGBDS, are you sure it's v0.6.0 that broke it?

[orbea]

I think this is an intentional change in rgbds.
I bisected it to commit gbdev/rgbds@d86d24b.
Which fixed rgbds issue gbdev/rgbds#1062.

d86d24bdc14fb2fc5c1ca9729495e1a26c2d6d08 is the first bad commit
commit d86d24bdc14fb2fc5c1ca9729495e1a26c2d6d08
Author: Rangi <[email protected]>
Date:   Fri Sep 30 17:13:55 2022 -0400

    Remove legacy support for generating a palette with unused colors
    
    If you need an explicit set of colors, possibly including
    unused ones, use `-c`.
    
    Fixes #1062

 src/gfx/pal_sorting.cpp | 25 -------------------------
 1 file changed, 25 deletions(-)

[orbea]

Changing the rgbgfx command line in the Makefile to rgbgfx -h -u -o $@ $< -c embeddedworks.

There are additionally many deprecated warnings including changing -h to -Z. I fear it may be impossible to support newer rgbds without breaking older rgbds...

[Rangi42]

You could check the value of rgbgfx -V and use flags depending on its version.

[orbea]

You could check the value of rgbgfx -V and use flags depending on its version.

I thought about that, but checking >= 0.6.0 with pure make is not straight forward. Or do you have an idea how?

[carmiker]

In my view it just makes sense to accept that 0.6.0 and beyond require a different set of command line switches and building SameBoy now requires >= 0.6.0. Anyone building this from source or packaging it up will have to contend with this now, and in the long run it is a non-issue. That being said, I think it makes sense to avoid changing command line switches often.

[Rangi42]

If you can assume that rgbasm has the same version as rgbgfx:

$(OBJ)/%.2bpp: %.png
	-@$(MKDIR) -p $(dir $@)
	@if test "$$(echo 'print __RGBDS_MAJOR__ || (!__RGBDS_MAJOR__ && __RGBDS_MINOR__ > 5)' | rgbasm -)" = '$$0'; then \
		rgbgfx -h -u -o $@ $<; \
	else \
		rgbgfx -Z -u -c embedded -o $@ $<; \
	fi

(or put that content in versioncheck.asm and do test "$$(rgbasm versioncheck.asm)" = '$$0';)

I think if/else/fi, test A = B, and $(command) are all POSIX sh.

[LIJI32]

In my view it just makes sense to accept that 0.6.0 and beyond require a different set of command line switches and building SameBoy now requires >= 0.6.0. Anyone building this from source or packaging it up will have to contend with this now, and in the long run it is a non-issue. That being said, I think it makes sense to avoid changing command line switches often.

I would generally agree, but considering many users install rgbds from a package manager, which are often behind by at least a few weeks, I'd rather avoid that. I like @Rangi42's solution.