Attention is currently required from: Bora Guvendik, Wonkyu Kim, Selma Bensaid, Jérémy Compostella, Nicholas Chin.
Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/67118 )
Change subject: libpayload/Makefile.inc: Initialize vboot depending on UPDATED_SUBMODULES ......................................................................
Patch Set 3:
(2 comments)
Patchset:
PS3:
I think providing the user the possibility to build with or without submodules is a nice feature. In such a case, it's user responsibility to ensure that all repos needed are installed properly.
Absolutely. Hence I want us to look for a solution that works by definition and not by coincidence. It is coincidence that the depthcharge Makefile doesn't unexport COREBOOT_EXPORTS. For other payloads that do it, your solution won't work. And it might break if somebody updates the depthcharge Makefile.
I can think some possible solutions: * add another variable that is meant to be set by the user and not unexported * never unexport UPDATED_SUBMODULES. but then we should rename it, e.g. put COREBOOT in the name so we don't leave a variable with generic name in the environment.
You didn't anwser my question btw. maybe there is nothing to do here: To avoid a checkout of the wrong commit in a submodule, you can always add the change to the index. Would that solve your problem?
File payloads/libpayload/Makefile.inc:
https://review.coreboot.org/c/coreboot/+/67118/comment/b65e2598_0df89044 PS2, Line 91: ifneq ($(UPDATED_SUBMODULES),1)
Hi Nico, are you building manually libpayload? […]
I meant Nicholas' case when running `make` in `payloads/coreinfo/`. I think it just calls `make` multiple times for libpayload. Once for the configuration and another time to actually build it. It's quite complicated. But in the end the result is the same as you'd type `make` twice, and the second invocation won't know what the first did.