coreboot

When completing the variant base for "snb_ivb_macs" starting from the current mb/apple/macbookair4_2 and already included upcoming macmini6_1/macbookpro9_2/macbookpro10_1 I'm currently hold back when adding the "macbookbpro10_1" which like the "macbookair4_2" also comes with its own spd folder.

Moving the spd folders to their own variants and having a subdirs-y += variants/$(VARIANT_DIR) inside the Makefile.mk of the base variant folder and a variant specific Makefile.mk including subdirs-y += spd or SPD_SOURCES += apple depending on the model, I stumble upon this error when building:

#BUILD FAILING
No rule to make target 'build/spd/apple.spd.hex', needed by 'build/spd.bin'.

However this can be worked around when src/lib/Makefile.mk line ~375 gets replaced, but I'm certain this will break other coreboot ports:

#SPD_OBJ_DIR := $(obj)/spd
SPD_OBJ_DIR := src/mainboard/$(MAINBOARDDIR)/variants/$(VARIANT_DIR)/spd

Although there is some wildcard defined at line ~390, adding the variant folder there won't make it work, but will fix listing the correct location of where spd files resides but cannot be found...

With this single line hack all 4 "snb_ivb_macs" variants not only build successful, but also share the same hash BUILD_TIMELESS=1 CONFIG_INCLUDE_CONFIG_FILE=n as their original port folder (if taking in account the following considerations that a ramstage linked file in variant folder is used on the original port and currently share the same CBFSSIZE & CMOS OPTIONS shared with the base "macbookair4_2").

I did find a similar SPD situation for some variants in mb/lenovo/sklkbl_thinkpad but that seems to have its own assistive SPD indexing workaround script mb/lenovo/sklkbl_thinkpad/spd/spd.c for the memory folder for "t470s" / "x280" and "t480s" having its own spd folder?

Is this hardcoded $(obj)/spd | build/spd a bug, or can this be worked around using the "correct" Makefile.mk subdirs or other SPD_SOURCES references?