On 01/16/19 19:57, Kinney, Michael D wrote:
> Hello,
>
> I shared an RFC in November to add an edk2-apps repository.
>
> https://lists.01.org/pipermail/edk2-devel/2018-November/00.html
>
> Feedback in this thread discussed that there are three types
> of applications. Apps that use libc, UEFI Shell apps,
> and UEFI Applications. I would like this RFC to focus on libc
> applications, and changes related to UEFI Shell apps and
> UEFI Applications can be handled separately. The updated
> RFC is shown below. The repo name has been changed from
> edk2-apps to edk2-libc based on feedback from Leif.
>
>
>
> I would like to propose the creation of a new
> repository called edk2-libc. This repository
> would initially be used to host the following
> packages from the edk2 repository:
>
> * AppPkg
> * StdLib
> * StdLibPrivateInternalFiles
>
> These 3 packages provide support for the libc along
> with applications that depend on libc. None of the
> other packages in the edk2 repository use these
> packages, so these 3 package can be safely moved
> without any impacts to platform firmware builds.
> Build configurations that do use libc features can
> clone the edk2-libc repository and add it to
> PACKAGES_PATH.
>
> The history of these 3 packages would be preserved
> when importing the content into edk2-libc. After
> the import is verified, these 3 packages would be
> deleted from the edk2 repository.
>
> This proposal helps reduce the size of the edk2
> repository and focuses edk2 repository on packages
> used to provide UEFI/PI conformant firmware.
>
> If there are no concerns with this proposal, I will
> enter a Tianocore BZs for the two steps.
It sounds good to me:
- PACKAGES_PATH is a useful feature and it works well in my experience,
so I think having to use PACKAGES_PATH for pulling in edk2-libc should
not be a large obstacle.
- I'm not sure how closely the StdLib internals are tied to day-to-day
changes in core edk2; that is, whether we should keep those histories
interlinked. That's something for the StdLib maintainers to evaluate.
Personally I don't remember many StdLib changes, so there seems to be a
genuine separation that supports the new repo idea.
Thanks,
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
