> On Apr 7, 2016, at 9:29 AM, Kinney, Michael D <michael.d.kin...@intel.com> > wrote: > > In the transition to github, we added the repository tianocore/udk > > https://github.com/tianocore/udk > > This is intended for UEFI Development Kit releases that are fully validated > releases based on EDK II. > We could consider putting binaries of the shell and FAT drivers in the UDK > repo and platforms that > prefer to use binaries of that content can pull those binaries from the UDK > repo. This way, the > edk2 repo can be just sources. >
Mike, +1 that is a good idea. Thanks, Andrew Fish > Best regards, > > Mike > > >> -----Original Message----- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >> Carsey, Jaben >> Sent: Thursday, April 7, 2016 8:04 AM >> To: Laszlo Ersek <ler...@redhat.com>; Justen, Jordan L >> <jordan.l.jus...@intel.com>; Ni, >> Ruiyu <ruiyu...@intel.com>; edk2-devel@lists.01.org <edk2-de...@ml01.01.org> >> Cc: Carsey, Jaben <jaben.car...@intel.com> >> Subject: Re: [edk2] [PATCH 03/12] FatBinPkg: Change to 2-clause BSD license >> >> >> >>> -----Original Message----- >>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >>> Laszlo Ersek >>> Sent: Thursday, April 07, 2016 12:30 AM >>> To: Justen, Jordan L <jordan.l.jus...@intel.com>; Ni, Ruiyu >>> <ruiyu...@intel.com>; edk2-devel@lists.01.org <edk2-de...@ml01.01.org> >>> Subject: Re: [edk2] [PATCH 03/12] FatBinPkg: Change to 2-clause BSD license >>> Importance: High >>> >>> On 04/07/16 08:16, Jordan Justen wrote: >>>> (How about an r-b for some of the patches I Cc'd you on? :) >>>> >>>> On 2016-04-06 19:11:05, Ni, Ruiyu wrote: >>>>> My understanding is: >>>>> >>>>> Shell is a very standalone project so the binary package was >>>>> created for a certain level of isolation. And it does save build >>>>> time. It also assumes that most of the users don’t need to >>>>> source debug the Shell. >>>>> >>>> >>>> I think you are correct that some people will make this 'time savings' >>>> argument about ShellBinPkg. I don't agree that it is worth it to keep >>>> the shell bins just as a time savings. We've been building it from >>>> source in OVMF, and I don't think it takes too long to build. (And, I >>>> think it is usually better to build from source.) >> >> The UEFI Shell has a binary package as a side effect of the EDK Shell having >> a binary >> package and wanting the same usage model for both. >> >> I think that the EDK Shell has a binary package since it was build outside >> of EDKII. >> >>> >>> For some perspective, it is not just the case that building OpenSslLib >>> dwarfs any other standalone module's build time; OpenSslLib's build time >>> exceeds everything else *together*, more or less. >>> >>> I always build on multiple threads. When I'm just working with my laptop >>> (= away from my workplace, which is at home BTW), that means "-n 4". >>> When I'm at home, I use distcc, and my home desktop computer >>> participates in the build (+4 threads). Now, the build tools very nicely >>> parallelize builds between independent modules (= separate INF files), >>> but source code for any given INF file is built serially. (I'm not >>> complaining about this, just saying.) >>> >>> The end result is that the build time can never be shorter than the >>> largest single module's build time, and that one is OpenSslLib, as far >>> as OvmfPkg and ArmVirtPkg is concerned. FatPkg and ShellPkg are >>> unnoticeable to me -- when I do a full rebuild, I always end up staring >>> at the OpenSSL source files scrolling on my screen, near the end of the >>> build. >>> >>> Plus (of course) the other problem with the BinPkgs is that they are >>> almost always out-of-date, relative to their source code. That's not >>> very helpful when the source and the binaries live in the exact same tree. >>> >>> Anyway, the BinPkg's don't impede my work, but they have a good >>> potential for confusion with bug reports on the list, etc. >>> >>>> Another argument may be is that it is difficult to setup your .dsc to >>>> have all of the parts needed for the Shell. This is true. It takes >>>> more than 20 lines in the .dsc. When they are duplicated in each >>>> platform, they can become out of sync. To solve this, maybe we can add >>>> a dsc include file like StdLib uses? >>> >>> Not a bad idea! >> >> I would love this. >> >> And the comment snipped below about moving towards removing the ShellBinPkg >> - It is >> very hard to know when is a good time to rebuild binaries for customers. I >> would love >> it if each customer built the shell from source at the revision that they >> want and >> moved beyond the binary precompiled versions. >> >>> >>> [snip] >>> >>>>> In someday, when FatBinPkg is no longer referenced by any >>>>> platform, we can safely remove it. >>>>> >>>> >>>> Do you mean platforms in the EDK II tree? My patches make it so no >>>> platforms in the EDK II tree are referencing FatBinPkg. >>>> >>>> I think you'll mean platforms outside of EDK II may be using it. I >>>> don't think it is fair to use this argument unless we can point to >>>> actual users of FatBinPkg. >>> >>> Seconded! >>> >>>> Otherwise, the argument will always be >>>> valid. ("Maybe someone is using it...") >>>> >>>> Will this mean we can never remove FatBinPkg because *maybe* someone >>>> is using it? >>>> >>>> What if we say something like: "We will leave it for 1 month so >>>> platforms can transition to using FatPkg" >>> >>> I agree. It would be nice if we could somehow insert a deprecation >>> warning into the build process. For example, add a new macro to the >>> [Defines] section in "FatBinPkg/EnhancedFatDxe/Fat.inf", and the build >>> tools would display a deprecation banner. (Something like the #warning >>> preprocessing directive in C, except #warning (a) is not standard C, (b) >>> would break the build, (c) is useless for binary-only packages.) >>> >>> Thanks >>> Laszlo >>> _______________________________________________ >>> 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
