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
