On 06/12/19 11:21, Leif Lindholm wrote: > On Wed, Jun 12, 2019 at 10:18:24AM +0200, Laszlo Ersek wrote: >>> In this instance, we explicitly don't care about the submodule for >>> that other project (and I really hope this is the norm) - so we >>> shouldn't be documenting steps that rely on that additional >>> submodule existing. >> >> Yes; this is why I suggested dropping "--recursive" from the >> instructions. As far as I remember, it was meant as a convenience for >> users cloning the edk2 repo from zero. > > But we've never actually relied on that behaviour, so it's not so much > convenience as cargo culting. > >>> This is why I am referring to anything other than a central definition >>> of the relationship between edk2 and its submodules as a workaround. I >>> am not suggesting any shortcomings in the technical aspect. >> >> Can you provide an example definition then? I'm having trouble imagining >> one. > > Laszlo, I think you've misunderstood me somewhere.
That's for certain. :) > What I am saying is: > - We should have a policy (i.e., a section in toplevel Readme.md) > regarding submodules. > - That policy *should* include the requirement to not permit > submodules requiring submodules for our purposes. > - That policy should include the steps required to get the edk2 > repository to a buildable state. > - Nothing related to submodules should be documented anywhere else > in the tree. Sure, OpenSSL-HOWTO.txt can still be there, but > the section "HOW to Install OpenSSL for UEFI Building" should go. Got it now. Good idea. Thanks! Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#42280): https://edk2.groups.io/g/devel/message/42280 Mute This Topic: https://groups.io/mt/31949273/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
