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.
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.
Regards,
Leif
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#42277): https://edk2.groups.io/g/devel/message/42277
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]
-=-=-=-=-=-=-=-=-=-=-=-
