Simplify dev builds

[philipanda]

No description provided.

[pietrushnic]

@philipanda seems to me like reinventing the wheel, but maybe @miczyg1 should confirm. We have an AIRGAP feature, which should be expanded to cover your use case. Sorry, I didn't deeply dive into your motivation (lack of time), but at first glance it seem to be the case.

[philipanda]

@philipanda seems to me like reinventing the wheel, but maybe @miczyg1 should confirm. We have an AIRGAP feature, which should be expanded to cover your use case. Sorry, I didn't deeply dive into your motivation (lack of time), but at first glance it seem to be the case.

It might be. I didn't dive deep too into it as the airgap wasn't really telling me much and it wasn't documented in the help or in the README.

[SergiiDmytruk]

Which use case is this meant to simplify? Is it about having a separate EDK2 checkout for development and pointing at it to build the ROM?

[philipanda]

Which use case is this meant to simplify? Is it about having a separate EDK2 checkout for development and pointing at it to build the ROM?

I'd like to have a local edk2 repo which can be freely modified and built using the build.sh. Without the hassle of modifying the kconfigs manually or using the menuconfig and modifying the build.sh to make it not purge the .config that contains a custom edk2 repo path & revision. It was always a hassle to me. When someday I've asked @mkopec what's the best way to build coreboot+edk2 to debug things, I've learned that it's best to just do it manually without the use of build.sh.

I'd also like to add an option to:

• open menuconfig before build
• keep the .config from being overwritten on every call

[pietrushnic]

@philipanda seems to me like reinventing the wheel, but maybe @miczyg1 should confirm. We have an AIRGAP feature, which should be expanded to cover your use case. Sorry, I didn't deeply dive into your motivation (lack of time), but at first glance it seem to be the case.

It might be. I didn't dive deep too into it as the airgap wasn't really telling me much and it wasn't documented in the help or in the README.

This is my bad. The source PR definitely has more explanation. If you feel it is not documented enough, you should submit an issue. There are various valid use cases, but bloat would not help us in maintenance. @macpijan we need some product/design thinking here.

[miczyg1]

@philipanda seems to me like reinventing the wheel, but maybe @miczyg1 should confirm. We have an AIRGAP feature, which should be expanded to cover your use case. Sorry, I didn't deeply dive into your motivation (lack of time), but at first glance it seem to be the case.

Yes it is an airgap scenario clearly.

Which use case is this meant to simplify? Is it about having a separate EDK2 checkout for development and pointing at it to build the ROM?

I think edk2 is heavy to clone, lots of submodules, waste of time, etc... By having a local copy of the repo with the submodules ready, it might be "easier" and faster...

[philipanda]

I think edk2 is heavy to clone, lots of submodules, waste of time, etc... By having a local copy of the repo with the submodules ready, it might be "easier" and faster...

It's not exactly about having a local copy, that's just the easiest way to allow to make a little change in edk2 and then build Dasharo in one command. Without pushing to the remote, managing the history there and modifying the .kconfig on every build.

I can't see what's wrong with the idea of reducing the time needed to build some change. From what I see from the AIRGAP PR it's about performing the builds offline as a security measure, not to simplify quick test builds, so to me, it's a completely different use case. If some functionality is common, there is no reason to duplicate it, but I still hold my stand.

[macpijan]

There are various valid use cases, but bloat would not help us in maintenance. @macpijan we need some product/design thinking here.

I do not compile edk2 as my daily job, so I'd like to hear how @SergiiDmytruk @miczyg1 @mkopec are doing this, and why it's a hassle for @philipanda ?

Certainly, building coreboot binary with local edk2 changes should be as easy as making changes in edk2 and hitting a build button, and I'm with @philipanda on this one.

[miczyg1]

Certainly, building coreboot binary with local edk2 changes should be as easy as making changes in edk2 and hitting a build button

It is that simple. coreboot will not overwrite changes or change branches in the cloned edk2 repo if it is dirty. What I sometimes do is local changes under payloads/external/edk2/workspace/Dasharo, rebuild with make and check. To trick coreboot to rebuild edk2 I just do rm build/UEFIPAYLOAD.fd

And once I consider the job done, I push the local changes to remote (although one may need to change the remote to SSH instead of HTTPS, and that's second trick to it)...

[SergiiDmytruk]

When someday I've asked @mkopec what's the best way to build coreboot+edk2 to debug things, I've learned that it's best to just do it manually without the use of build.sh.

Yep. I avoid build.sh or, when I have to, run it in a separate worktree to not lose my changes once again. The unconditional reinitialization the script does and removal of EDK make it unsuitable for development. The idiosyncrasies of payloads/external/edk2/Makefile (removing build directory every time, detaching from branches) make things inconvenient enough even without build.sh (luckily EDK uses ccache by default)

I ended up thinking of build.sh as something non-developers and CI use to build a ROM once and then throw everything away (why entire history and all possible submodules are often downloaded just for this is a separate thing, which probably makes CI run longer than it could).

I guess 79fd21a is better than nothing but it doesn't address submodules that in case of EDK consume most of the build time (OpenSSL mostly). I tried to work around that by configuring git to replace remote URLs with local repos but build.sh always uses Docker which gets in the way (and to be practical this also needs some script to synchronize local mirrors):

[url "/home/user/repos/deps-cache/stm"]
    insteadOf = https://review.coreboot.org/STM

Other options I thought about were read-only/copy-on-write bindfs/overlayfs/docker mounts to be able to mix normal and build.sh build in the same worktree.