Sent from my iPhone
> On Aug 28, 2014, at 10:56 AM, "Kinney, Michael D" > <michael.d.kin...@intel.com> wrote: > > Andrew, > > A [Packages] section in the DSC file would be global and would not support > multiple versions of the same package installed in a WORKSPACE with different > modules requiring different versions of the same package to build. > > If and only if you had a single version of each package in WORKSPACE would > this be unambiguous. > Which is what I want. The multiple versions was forced by running UPT. > Mike > > -----Original Message----- > From: Tim Lewis [mailto:tim.le...@insyde.com] > Sent: Monday, August 25, 2014 11:07 PM > To: edk2-devel@lists.sourceforge.net > Subject: Re: [edk2] [Patch 2/2] [MdePkg] INF/DEC file updates to EDK II > packages > > Andrew -- > > Your 1st example works for me also. > > Tim > > -----Original Message----- > From: Andrew Fish [mailto:af...@apple.com] > Sent: Tuesday, August 26, 2014 2:01 PM > To: edk2-devel@lists.sourceforge.net > Subject: Re: [edk2] [Patch 2/2] [MdePkg] INF/DEC file updates to EDK II > packages > > >> On Aug 25, 2014, at 10:12 PM, Tim Lewis <tim.le...@insyde.com> wrote: >> >> Liming -- >> >> I think the real problem is: I don't like having tools change *any* files in >> other packages. This has been a long-standing issue with EDK2 and the >> packaging spec. Source code control can detect a 1 byte difference and show >> it as a change to me. Then I must do a file compare to determine if the >> change is real or not. >> >> Every other item in the EDK2 build system can be controlled through the .dsc >> or the .fdf file *except* the location of package .dec files. So, why not >> add a section to the .dsc file to specify the location of the package files. >> If the [Packages] section in an INF has no path, then look it up in the >> .dsc file. Otherwise use the path specified in the .inf file. >> >> Something like this: >> .dsc >> >> [Packages] >> MdePkg.dec|MdePkg\MdePkg.dec (match MdePkg.dec from INF and use >> $(WORKSPACE)-relative 2nd half) > > Tim, > > I think this would be easier to implement, and understand: > [Packages] > MdePkg/MdePkg.dec | Core/MdePkg/MdePkg.dec > > So basically original package location vs. shifted location in this build > tree. It also does not require any changes to support non adjusted .dec paths. > > An alternate form could be the path to pre-pend: > [Packages] > MdePkg/MdePkg.dec | Core > > > I made a cheap hack to add an environment variable called ALT_WORKSPACE to > add alternate places to search for .dec files. > export ALT_WORKSPACE="$WORKSPACE/edk2/;$WORKSPACE/Vendor/Xyz/XyzProjectK/" > > So in this example the search path for a *.dec would be $WORKSPACE, then > "$WORKSPACE/edk2, and $WORKSPACE/Vendor/Xyz/XyzProjectK/. Basically the edk2 > is a subdirectory in the tree, and the vendor code is not all in the root of > the tree. Putting the info in the .dsc file would be a better solution, but > the ALT_WORKSPACE environment variable is only requires a few lines of new > Python code. > > Thanks, > > Andrew Fish > >> Tim >> >> >> -----Original Message----- >> From: Gao, Liming [mailto:liming....@intel.com] >> Sent: Tuesday, August 26, 2014 1:05 PM >> To: edk2-devel@lists.sourceforge.net >> Subject: Re: [edk2] [Patch 2/2] [MdePkg] INF/DEC file updates to EDK >> II packages >> >> Andrew: >> Yes. 100% change in INF file should be the path difference if they are from >> the same package.dist file. But, if original one is not UPT clean, the >> difference will be hard to be seen. >> >> The main UPT change is [Section] order and some alignment. Why do you think >> it will bring hard to the real work? >> >> Thanks >> Liming >> -----Original Message----- >> From: Andrew Fish [mailto:af...@apple.com] >> Sent: Tuesday, August 26, 2014 11:38 AM >> To: edk2-devel@lists.sourceforge.net >> Subject: Re: [edk2] [Patch 2/2] [MdePkg] INF/DEC file updates to EDK >> II packages >> >> >>> On Aug 25, 2014, at 7:01 PM, Gao, Liming <liming....@intel.com> wrote: >>> >>> Jordan: >>> The real requirement is that some users use UPT to install core package >>> into the different directories, such as Core\MdePkg. After the >>> installation, they want to easily compare the original package and >>> installed package. >> >> How is this compare done? How is it going to be easy if I get the weakly >> development version from some one who has a different location for the >> MdePkg than in my tree? So I will get a diff hit on 100% of the INF files, >> when I really just looking for the incremental changes. Not the relative >> changes caused by the path differences. >> >> How does the build deal with MdePkg and MdeModulePkg containing >> MdePkg/MdePkg.dec and the "Other code" containing Core/MdePkg/MdePkg.dec. >> How do I combine edk2 + vendor a + vendor b code together in a working tree >> and still grep against their original drops? As the edk2, vendor a, and >> vendor b should all not get the final say in the tree structure we end up >> with. Do I need to put all the edk2 packages in / (edk2) Core/ (vendor a) >> and edk2/ (vendor b) so each version matches? >> >> Currently we work around this by adding search paths to $WORKSPACE as a >> local hack to the BaseTools. >> >> Also when is this stuff going to be real? It looks like UDK 2014 is svn tags >> and a Zip file of code. Does that mean the UDK 2017 (2014 + (2014 - 2011)) >> we will use UPT to install the packages as the only option? The folks doing >> Core\MdePkg also like to release zip files with code. So all this UPT >> cleanup is making getting real work done harder... >> >> Seems like you guys should add some features to the build system so that >> daily development is not made worse by these UPT changes. >> 1) Allow search paths in the $WORKSPACE. So if some one moves the edk2 >> packages to Core/ you can add $(WORKSPACE)/Core as a search path and not >> need to change every INF in the system. >> 2) Given the current UPT cleanup we should add $WORKSPACE aliases so you >> don't need to have MdePkg in /, Core/, and edk2/. >> >> Thanks, >> >> Andrew Fish >> >> >>> This change is required by EDKII project major release, but not required >>> for daily development. >>> >>> The section order will not be changed unless new section are introduced in >>> INF/DEC. >>> >>> Yes. Those changes are directly output from UPT tool. And, we have test to >>> cover this tool. So, I have confidence. >>> >>> So far, I have no branch for those change. If you request, I could send zip >>> the source INF/DEC (before UPT and after UPT) to you. >>> >>> Thanks >>> Liming >>> -----Original Message----- >>> From: Jordan Justen [mailto:jljus...@gmail.com] >>> Sent: Tuesday, August 26, 2014 5:03 AM >>> To: edk2-devel@lists.sourceforge.net >>> Subject: Re: [edk2] [Patch 2/2] [MdePkg] INF/DEC file updates to EDK >>> II packages >>> >>>> On Mon, Aug 25, 2014 at 3:17 AM, Gao, Liming <liming....@intel.com> wrote: >>>> Hi, all >>>> >>>> This patch is for below ITEM 7. INF/DEC are generated from UPT tool. >>>> DEC_SPECIFICATION and INF_VERSION will be updated to 0x00010017. >>>> Please help review them. >>>> >>>> MdePkg: Make sure order of DEC/INF content matches the order that >>>> UPT generates in the XML -> INF conversion >>> >>> This patch subject line is much longer than the recommended 70 character >>> limit: >>> https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message- >>> F >>> ormat >>> >>> How about: >>> MdePkg DEC/INF: Match format required by UPT >>> >>> These changes seem to arbitrarily match the 'order of some tool', but why >>> is that required? >>> >>> What happens when someone edits these files, and doesn't get the order >>> 'just right'? >>> >>> Is the order that UPT uses strict, or will it potentially change in the >>> future, if for example, the version of some library being used by the tool >>> decides to change the way it orders things. >>> >>> There seems to be other formatting happening, such as spaces removed from >>> the copyright notice. >>> >>> All this rolled up into a single change seems to have produced something >>> that is not reviewable in a reasonable amount of time. >>> >>> Another question I have is, were these changes the result of the output of >>> the tool? I guess it would be easier to have some confidence in the output >>> of a tool rather than all of these changes having been manually applied. >>> >>> Do you have the changes available in a branch to make it easy to test? >>> (No, I would not want an svn branch to be added for this.) >>> >>> -Jordan >>> >>>> 1) Section Order in INF/DEC to match the ones generated from UPT >>>> >>>> 2) Guid value in section will be align. >>>> >>>> 3) Usage comments in section will be align. >>>> >>>> 4) One PCD section includes one PCD type. If one PCD supports more PCD >>>> types, it will be listed in each PCD type section in DEC file. >>>> >>>> >>>> >>>> Contributed-under: TianoCore Contribution Agreement 1.0 >>>> >>>> Signed-off-by: Gao, Liming <liming....@intel.com> >>>> >>>> >>>> >>>> Thanks >>>> >>>> Liming >>>> >>>> From: Gao, Liming [mailto:liming....@intel.com] >>>> Sent: Thursday, August 14, 2014 10:13 AM >>>> To: edk2-devel@lists.sourceforge.net >>>> Subject: [edk2] [Patch 1/2] [MdePkg] INF/DEC file updates to EDK II >>>> packages >>>> >>>> >>>> >>>> Hi, all >>>> >>>> Could you help review this patch? It includes the following changes >>>> 1-6 for MdePkg. The patch is a little big. For new added UNI file, I >>>> zip them together. >>>> >>>> >>>> >>>> The second patch for below item 7 will be sent later >>>> >>>> >>>> >>>> Thanks >>>> >>>> Liming >>>> >>>> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] >>>> Sent: Thursday, August 07, 2014 5:32 AM >>>> To: edk2-devel@lists.sourceforge.net >>>> Subject: [edk2] INF/DEC file updates to EDK II packages >>>> >>>> >>>> >>>> Hello, >>>> >>>> >>>> >>>> I wanted to let everyone know about a number of patch reviews for >>>> EDK II packages that will be sent out over the next couple of weeks. >>>> These patches impact the order of content in INF/DEC files and >>>> comment blocks in INF/DEC files, and should not have any build or >>>> functionality impacts. These patches will address the following issues: >>>> >>>> >>>> >>>> 1) Usage information in INF file comment blocks are either incomplete >>>> or incorrect. This includes usage information for >>>> Protocols/PPIs/GUIDs/PCDs/HOBs/Events/BootModes. The syntax for >>>> usage information in comment blocks is defined in the EDK II Module >>>> Information >>>> (INF) Specification >>>> >>>> 2) Add MODULE_UNI_FILE to INF [Defines] section along with UNI file >>>> that contains the localized Abstract and Description of a module. >>>> >>>> a. Addresses an information gap between INF files and the UEFI >>>> Distribution Packaging Specification XML schema >>>> >>>> b. There will be an associated update to UPT in BaseTools to consume >>>> MODULE_UNI_FILE and associated UNI file during UDP creation that >>>> performs the INF -> XML conversion. >>>> >>>> c. There will be an associated update to UPT in BaseTools to produce >>>> MODULE_UNI_FILE and associated UNI file during UDP installation that >>>> performs the XML -> INF conversion. >>>> >>>> 3) Add [UserExtensions.TianoCore."ExtraFiles"] section to INF files >>>> along with associated UNI file that provides the localized Name of a >>>> module. >>>> >>>> a. [UserExtensions.TianoCore."ExtraFiles"] provides an easy method >>>> for >>>> a module to specify extra files not listed in [Sources] or >>>> [Binaries] sections to be added to a UDP without having to list the >>>> files in the UPT package information data file. >>>> >>>> b. There will be an associated update to UPT in BaseTools to package >>>> up >>>> files listed in [UserExtensions.TianoCore."ExtraFiles"] during UDP >>>> creation. >>>> >>>> c. UNI file contains localized name of a module to go along with the >>>> localized Abstract and Description from the MODULE_UNI_FILE. >>>> >>>> 4) PCD information in DEC file comment blocks are either incomplete or >>>> incorrect. This includes detailed description, @Prompt, >>>> @ValidRange, @ValidList, @Expression, and [Error.<TokenSpaceGuid>] >>>> validation error messages >>>> >>>> 5) Add PACKAGE_UNI_FILE to DEC [Defines] section along with UNI file >>>> that contains the localized Abstract and Description of a package >>>> and localized strings associated with PCDs. >>>> >>>> a. Addresses an information gap between DEC files and the UEFI >>>> Distribution Packaging Specification XML schema >>>> >>>> b. There will be an associated update to UPT in BaseTools to consume >>>> PACKAGE_UNI_FILE and associated UNI file during UDP creation that >>>> performs the DEC -> XML conversion. >>>> >>>> c. There will be an associated update to UPT in BaseTools to produce >>>> PACKAGE_UNI_FILE and associated UNI file during UDP installation >>>> that performs the XML -> DEC conversion. >>>> >>>> 6) Add [UserExtensions.TianoCore."ExtraFiles"] section to DEC files >>>> along with associated UNI file that provides the localized Name of a >>>> package. >>>> >>>> a. [UserExtensions.TianoCore."ExtraFiles"] provides an easy method >>>> for >>>> a package to specify extra files to be added to a UDP without having >>>> to list the files in the UPT package information data file. >>>> >>>> b. There will be an associated update to UPT in BaseTools to package >>>> up >>>> files listed in [UserExtensions.TianoCore."ExtraFiles"] during UDP >>>> creation. >>>> >>>> c. UNI file contains localized name of a package to go along with the >>>> localized Abstract and Description from the PACKAGE_UNI_FILE. >>>> >>>> 7) Make sure order of DEC/INF content matches the order that UPT >>>> generates in the XML -> INF conversion >>>> >>>> a. This allows UDP packages installed by UPT to be compared against >>>> EDK II trunk/branches using standard diff utilities. >>>> >>>> >>>> >>>> Patches for the following EDK II packages are being prepared >>>> >>>> 1) MdePkg >>>> >>>> 2) MdeModulePkg >>>> >>>> 3) IntelFrameworkPkg >>>> >>>> 4) IntelFrameworkModulePkg >>>> >>>> 5) FatPkg >>>> >>>> 6) ShellPkg >>>> >>>> 7) PcAtChipsetPkg >>>> >>>> 8) UefiCpuPkg >>>> >>>> 9) SourceLevelDebugPkg >>>> >>>> 10) CryptoPkg >>>> >>>> 11) SecurityPkg >>>> >>>> 12) NetworkPkg >>>> >>>> >>>> >>>> Best regards, >>>> >>>> >>>> >>>> Mike >>>> >>>> >>>> >>>> >>>> -------------------------------------------------------------------- >>>> - >>>> - >>>> -------- >>>> Slashdot TV. >>>> Video for Nerds. Stuff that matters. >>>> http://tv.slashdot.org/ >>>> _______________________________________________ >>>> edk2-devel mailing list >>>> edk2-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/edk2-devel >>> >>> --------------------------------------------------------------------- >>> - >>> -------- >>> Slashdot TV. >>> Video for Nerds. Stuff that matters. >>> http://tv.slashdot.org/ >>> _______________________________________________ >>> edk2-devel mailing list >>> edk2-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/edk2-devel >>> --------------------------------------------------------------------- >>> - >>> -------- >>> Slashdot TV. >>> Video for Nerds. Stuff that matters. >>> http://tv.slashdot.org/ >>> _______________________________________________ >>> edk2-devel mailing list >>> edk2-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/edk2-devel >> >> >> ---------------------------------------------------------------------- >> -------- >> Slashdot TV. >> Video for Nerds. Stuff that matters. >> http://tv.slashdot.org/ >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/edk2-devel >> >> ---------------------------------------------------------------------- >> -------- >> Slashdot TV. >> Video for Nerds. Stuff that matters. >> http://tv.slashdot.org/ >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/edk2-devel >> >> ---------------------------------------------------------------------- >> -------- >> Slashdot TV. >> Video for Nerds. Stuff that matters. >> http://tv.slashdot.org/ >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/edk2-devel > > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
