Re: [RFC] Proposal to add edk2-apps repository

["Ni, Ruiyu" <ruiyu.ni@intel.com>]

Krishna,
The reason there are applications inside MdeModulePkg/Application is that the shell protocol was in ShellPkg when the app was developed and MdeModulePkg cannot depend on ShellPkg (rule).
Now since shell protocol is moved to MdePkg, any apps can depend on shell protocol. (In fact they wanted to but just wasn't allowed due to reason above.)

I even prefer to move the ShellPkg to the edk2-app repo Mike proposed. Instead of enlarge the ShellPkg:)

I don't prefer edk2-libc unless we have a strategy/plan to make ordinary C developer easy by promoting the std-c pkg.
The other reason I prefer edk2-app is then ShellPkg might be moved to that new repo.


> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
> krishnaLee
> Sent: Friday, November 30, 2018 9:45 AM
> To: edk2-devel@lists.01.org
> Subject: Re: [edk2] [RFC] Proposal to add edk2-apps repository
> 
> Kinney,
> I always think there may be two kinds of apps:
> 1,some apps have dependency on uefi_shell(shell-lib,efi_shell_protocol,...they
> usually execute under uefi_shell),I would call them "uefi_shell_application";
> 2,some apps have no dependency on uefi_shell(such as apps in
> MdeModulePkg/Application),I would call them "standard_uefi_application".
> 
> The "AppPkg / StdLib / StdLibPrivateInternalFiles" packages are usually used by
> uefi_shell_application,I think they can all move to ShellPkg,no need to create
> new package ?
> 
> 
> Thanks,
> krishna.
> 
> At 2018-11-30 08:46:58, "Kinney, Michael D" <michael.d.kinney@intel.com>
> wrote:
> >Leif,
> >
> >I did consider the edk2-libc name.  The port of Python 2.7 is in the
> >AppPkg as well and it uses libc.
> >
> >So the content of this new package is a combination of libc And apps
> >that use libc.
> >
> >I am definitely open to alternate names.  2 options so far:
> >
> >* edk2-apps
> >* edk2-libc
> >
> >Thanks,
> >
> >Mike
> >
> >> -----Original Message-----
> >> From: Leif Lindholm [mailto:leif.lindholm@linaro.org]
> >> Sent: Thursday, November 29, 2018 2:41 PM
> >> To: Kinney, Michael D <michael.d.kinney@intel.com>
> >> Cc: edk2-devel@lists.01.org
> >> Subject: Re: [edk2] [RFC] Proposal to add edk2-apps repository
> >>
> >> On Thu, Nov 29, 2018 at 05:58:08PM +0000, Kinney, Michael D wrote:
> >> > Hello,
> >> >
> >> > I would like to propose the creation of a new repository called
> >> > edk2-apps.  This repository would initially be used to host the
> >> > following packages from the edk2 repository:
> >> >
> >> > * AppPkg
> >> > * StdLib
> >> > * StdLibPrivateInternalFiles
> >>
> >> Let me start by saying I 100% back moving these out of the main edk2
> >> repository.
> >>
> >> > 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-apps repository and add it to PACKAGES_PATH.
> >>
> >> I must confess to never having properly understood the scope of
> >> AppPkg to begin with.
> >>
> >> AppPkg/Applications/Hello does not appear to have any further (real)
> >> dependency on libc than MdeModulePkg/Application/HelloWorld/, and .
> >>
> >> And certainly MdeModulePkg/Applications contain plenty of ...
> >> applications.
> >>
> >> So, if the purpose is simply to provide some examples of application
> >> written to libc rather than UEFI - should this be edk2- libc instead?
> >>
> >> Best Regards,
> >>
> >> Leif
> >>
> >> > The history of these 3 packages would be preserved when importing
> >> > the content into edk2-apps.  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.
> >> >
> >> > Best regards,
> >> >
> >> > Mike
> >> > _______________________________________________
> >> > edk2-devel mailing list
> >> > edk2-devel@lists.01.org
> >> > https://lists.01.org/mailman/listinfo/edk2-devel
> >_______________________________________________
> >edk2-devel mailing list
> >edk2-devel@lists.01.org
> >https://lists.01.org/mailman/listinfo/edk2-devel
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel