Mike, As Krishna points out there are flavors of Apps. Do we want to have different packages for different flavor of apps, or different dirs in a more generic App package? Maybe we should define classes of UEFI Applications in the README.md and give them a place to live.
I don't want to get too pedantic so we can have a 1st level of if you depend on X you go here. Maybe something if you depend on the clib you go in the Clib dir, if you depend on Shell you go in Shell. With a priority to the list so clib always means clib dir. etc.? Thanks, Andrew Fish > On Nov 29, 2018, at 5:44 PM, krishnaLee <sssky...@163.com> wrote: > > 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.kin...@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.lindh...@linaro.org] >>> Sent: Thursday, November 29, 2018 2:41 PM >>> To: Kinney, Michael D <michael.d.kin...@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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
