Attention is currently required from: Bora Guvendik, Wonkyu Kim, Selma Bensaid, Jérémy Compostella, Nicholas Chin.

View Change

2 comments:

• Patchset:

  • Patch Set #3:

    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:

  • Patch Set #2, 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.

To view, visit change 67118. To unsubscribe, or for help writing mail filters, visit settings.