Menu
▾
▴
edk2-buildtools-devel — EDK II Build Tools Developer discussions
You can subscribe to this list here.
| 2010 |
Jan
(1) |
Feb
(2) |
Mar
(12) |
Apr
(3) |
May
(2) |
Jun
(16) |
Jul
(24) |
Aug
(3) |
Sep
(9) |
Oct
(9) |
Nov
(1) |
Dec
(10) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011 |
Jan
(8) |
Feb
(4) |
Mar
(6) |
Apr
(9) |
May
(4) |
Jun
(32) |
Jul
(14) |
Aug
|
Sep
(24) |
Oct
(26) |
Nov
(34) |
Dec
(15) |
| 2012 |
Jan
(16) |
Feb
(27) |
Mar
(44) |
Apr
(10) |
May
(8) |
Jun
(15) |
Jul
(10) |
Aug
(15) |
Sep
(12) |
Oct
(4) |
Nov
(3) |
Dec
(16) |
| 2013 |
Jan
(8) |
Feb
(4) |
Mar
(8) |
Apr
(7) |
May
(22) |
Jun
(17) |
Jul
(18) |
Aug
(31) |
Sep
(19) |
Oct
(16) |
Nov
(26) |
Dec
(11) |
| 2014 |
Jan
(21) |
Feb
(23) |
Mar
(17) |
Apr
(19) |
May
(39) |
Jun
(33) |
Jul
(86) |
Aug
(11) |
Sep
(5) |
Oct
(19) |
Nov
(1) |
Dec
(2) |
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Kinney, M. D <mic...@in...> - 2014-07-21 18:13:30
|
Hi, Thank you to everyone who provided feedback. There were no comments against this proposal, and there was feedback to make some refinements and clarifications. The detailed proposal with these updates is shown below. We will start the transition this week. We may need help from the EDK II community on some of the OS specific scripts to build BaseTools from sources and scripts to pull BaseTools binaries from https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/. Proposed steps: =============== 1) Create new sub-project for BaseTools binaries a. SVN Link: https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/ b. Status: Done. 2) Intel to provide Build System for BaseTools Win32 binaries a. SVN Link: https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/Win32/ b. Build Frequency: Once per day, but only if there are source changes since last build. Incremental build c. Build Time: 3 AM PDT d. Daily builds are incremental. This means that different tool binaries may have different versions based on the source control system revision used to perform incremental builds. e. Clean builds of BaseTools will only be done when a release branch is created or on-request if there are issues found with incremental build. d. If build fails for any reason, then build server sends build log to edk...@li... and no new binaries are checked into https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/. e. If build succeeds then new binaries are checked into https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/. A build report in ReadMe.txt. is checked into the OS specific sub-directory. f. Initial Build System configuration ############### Build System Information ############### OS_Name = Windows Server 2008 R2 Enterprise (X64) OS_Version = 6.1.7601 Service Pack SP1 Build 7601 Visual Studio = Microsoft Visual Studio Team System 2008 Team Suite SP 1 Python = 2.7.3 (32bit) cxFreeze = 4.2.3 antlr3 = 3.1.3 McAfee VirusScan Enterprise 8.8 f. Status: In progress. Need a few more validation steps. 3) Delete Win32 binaries from EDK II BaseTools and replace with an SVN extern. a. Default will continue to pull Win32 binaries b. Developers that do not want Win32 binaries can opt-out by ignoring externs. c. Date: TBD. Goal is immediately after Build System for BaseTools Win32 binaries is stable. 4) Merge sources from Edk2-buildtools to EDK II BaseTools a. Date: TBD. Goal is immediately after Build System for BaseTools Win32 binaries is stable. 5) Change permissions on Edk2-buildtools sub-project to read-only and mark sub-project as inactive. a. Date: TBD. Goal is immediately after EDK II BaseTools is synced with EDK2-buildtools. 6) Retire edk...@li... mailing list. All commits to BaseTools sources will show up on edk...@li.... 7) Retire edk...@li... and move all BaseTools related discussions to edk...@li... 8) Update edksetup.* to optionally build BaseTools from sources or pull BaseTools binaries from source control a. edksetup.* detects if binaries are present or not b. If BaseTools binaries not present, and no flags provided, then edksetup.* displays help for building BaseTools from sources or pulling BaseTools binaries from source control if applicable. c. If binaries not present, and flag to build BaseTools from sources specified, then build BaseTools from sources. d. If binaries not present, and flag to pull BaseTools binaries from source control specified, then use command line source control tools to pull BaseTools binaries from source control. e. edksetup.* to support optional flag to specify an alternate BaseTools binary directory to avoid potential source control system conflicts with BaseTools\Bin. This would allow a developer to have binaries build by Build System and locally build binaries present in the same workspace. f. Date: TBD. Goal is immediately after all tasks above have been completed. Work on the updates scripts has been started and proposed flags and details will be shared this week. g. NOTE: There are additional discussions on binaries from alternate distribution locations. Edksetup.* may need additional updates/maintenance to detect and pull from these alternate distribution locations as required. Thanks, Mike -----Original Message----- From: Kinney, Michael D [mailto:mic...@in...] Sent: Thursday, July 10, 2014 4:12 PM To: edk...@li...; edk...@li... Subject: [edk2-buildtools] [edk2][RFC] Proposal to retire edk2-buildtools sub-project Hello, I am looking for comments on a proposal on how EDK II BaseTools is maintained. The goal is to move all tool related development activities to the EDK II BaseTools. This is to address community feedback that there are long delays between changes made to the edk2-buildtools sub-project and the changes being propagated to EDK II BaseTools. There has also been feedback that some developers do not want the overhead of pulling Win32 binaries when they are not required. I am interested in your feedback (positive or negative) on this proposal and if you think steps should be added or removed or modified. I would appreciate feedback by 7/18/2014. Please let us know if you need more time to evaluate this proposal. Proposed steps: =============== 1) Create new sub-project for BaseTools binaries a. SVN Link: https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/ b. Status: Done. 2) Intel to provide build server for BaseTools Win32 binaries a. SVN Link: https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/Win32/ b. Build Frequency: Once per day, but only if there are source changes since last build. c. Build Time: 3 AM PDT d. Build server to send email with build log when build is performed. e. Build server send email that no build was required if no source changes since last build. f. Status: In progress. Need a few more validation steps. 3) Delete Win32 binaries from EDK II BaseTools and replace with an SVN extern. a. Default will continue to pull Win32 binaries b. Developers that do not want Win32 binaries can opt-out by ignoring externs. c. Date: TBD. Goal is immediately after build server is stable. 4) Merge sources from Edk2-buildtools to EDK II BaseTools a. Date: TBD. Goal is immediately after build server is stable. 5) Change permissions on Edk2-buildtools sub-project to read-only and mark sub-project as inactive. a. Date: TBD. Goal is immediately after EDK II BaseTools is synced with EDK2-buildtools. 6) Retire edk...@li... mailing list. All commits to BaseTools sources will show up on edk...@li.... 7) Retire edk...@li... and move all BaseTools related discussions to edk...@li... Thanks, Mike ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ edk2-buildtools-devel mailing list edk...@li... https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel |
|
From: Andrew F. <af...@ap...> - 2014-07-17 18:38:22
|
On Jul 17, 2014, at 10:20 AM, Kinney, Michael D <mic...@in...> wrote: > Jim, > > Can you please provide details or an example that fails when using an AsBuilt INF? I would like to see if there is something that can be done quickly to resolve your specific issues. > > I agree that tools that do not need to use sources should not fail or generate an error if the sources are not present. We can investigate this. I do suspect, as you do, that a common parser is involved, and that parse will need adjustments for tools that do not require sources. > I’d like to see more flexibility too, but how do we tell the difference between this caae and a bug where the DSC and FDF are out of sync? Thanks, Andrew Fish > Thanks, > > Mike > > From: Jim...@De... [mailto:Jim...@De...] > Sent: Thursday, July 17, 2014 9:02 AM > To: Kinney, Michael D > Cc: edk...@li... > Subject: RE: Building from Binaries > > Thanks, Mike. > > I understand that and have been down that road. Unfortunately, ACPI tables > and a couple of other "special" things foiled that approach for me. > > In any case, I would still like to know why GenFds is looking for the presence > of source files, when it is supposed to assemble the binaries that have already > been built. This seems totally wrong. > > Regards, > Jim > > > From: Kinney, Michael D [mailto:mic...@in...] > Sent: Thursday, July 17, 2014 10:38 AM > To: Dailey, Jim; edk...@li... > Subject: RE: Building from Binaries > > Jim, > > When you build from sources in EDK II, the binaries are generated and an AsBuilt INF is also generated in the build output directory. The AsBuilt INF does not list the sources and only lists the binaries. If you use the AsBuild INF in your FDF file, then GenFds will not see a [Sources] section. > > Thanks, > > Mike > > From: Jim...@De... [mailto:Jim...@De...] > Sent: Thursday, July 17, 2014 8:20 AM > To: edk...@li... > Subject: [edk2-buildtools] Building from Binaries > > I want to be able to supply a directory tree having tools and binaries from > an already built EDK2 BIOS. This would be useful so that, for example, the > provider of a driver which is included in the BIOS can rebuild the BIOS with > newer or different versions of the driver for debug and/or development. > > It seems that GenFds quits when it can't find the first source file listed > in the first INF in the first FV it encounters in the FDF: > > Generate Region at Offset 0x0 > Region Size = 0x470000 > Region Name = FV > > Generating FVMAIN_COMPACT FV > > Generating FVMAIN FV > > > GenFds... > <drive>:\<path>\<INF file name>.inf(20): error 000E: File/directory not > found in workspace > <drive>:\<path>\<include file name>.h > NMAKE : fatal error U1077: 'GenFds' : return code '0xe' > Stop. > > My question is, why does GenFds care about source files at all when its > "user manual" states: > > The output of the first phase of an EDK II build (as defined in > the EDK II Build Specification) generates valid PE32/PE32+/Coff > image files. GenFds performs the second phase of the build process > during which consumes the images generated during the first phase, > using statements and rules defined in the FDF file to place the > PE32/PE32+/Coff images files into one or more EFI sections. > > GenFds requiring the presence of source files seems like a defect in the way > the tool behaves or is described in the manual. > > My guess is the problem stems from using "generic" code that not only parses > the FDF, but delves into the files it includes in a way that is not needed by > (and in this case is detrimental to the operation of) GenFds. > > Can this be corrected? > > Can you recommend a process to accomplish my goal of building strictly from > existing binary files? > > Regards, > Jim > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds_______________________________________________ > edk2-buildtools-devel mailing list > edk...@li... > https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel |
|
From: Andrew F. <af...@ap...> - 2014-07-17 18:36:10
|
On Jul 17, 2014, at 8:20 AM, Jim...@De... wrote: > I want to be able to supply a directory tree having tools and binaries from > an already built EDK2 BIOS. This would be useful so that, for example, the > provider of a driver which is included in the BIOS can rebuild the BIOS with > newer or different versions of the driver for debug and/or development. > Jim, There is a different INF syntax for just grab the binary. Maybe you could add a 2nd INF for the just grab the binary case? https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/UefiShell.inf [Binaries.Ia32] PE32|Ia32/Shell.efi|* [Binaries.X64] PE32|X64/Shell.efi|* [Binaries.ARM] PE32|Arm/Shell.efi|* [Binaries.AArch64] PE32|AArch64/Shell.efi|* Thanks, Andrew Fish > It seems that GenFds quits when it can't find the first source file listed > in the first INF in the first FV it encounters in the FDF: > > Generate Region at Offset 0x0 > Region Size = 0x470000 > Region Name = FV > > Generating FVMAIN_COMPACT FV > > Generating FVMAIN FV > > > GenFds... > <drive>:\<path>\<INF file name>.inf(20): error 000E: File/directory not > found in workspace > <drive>:\<path>\<include file name>.h > NMAKE : fatal error U1077: 'GenFds' : return code '0xe' > Stop. > > My question is, why does GenFds care about source files at all when its > "user manual" states: > > The output of the first phase of an EDK II build (as defined in > the EDK II Build Specification) generates valid PE32/PE32+/Coff > image files. GenFds performs the second phase of the build process > during which consumes the images generated during the first phase, > using statements and rules defined in the FDF file to place the > PE32/PE32+/Coff images files into one or more EFI sections. > > GenFds requiring the presence of source files seems like a defect in the way > the tool behaves or is described in the manual. > > My guess is the problem stems from using "generic" code that not only parses > the FDF, but delves into the files it includes in a way that is not needed by > (and in this case is detrimental to the operation of) GenFds. > > Can this be corrected? > > Can you recommend a process to accomplish my goal of building strictly from > existing binary files? > > Regards, > Jim > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds_______________________________________________ > edk2-buildtools-devel mailing list > edk...@li... > https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel |
|
From: Kinney, M. D <mic...@in...> - 2014-07-17 17:22:51
|
Jim,
Can you please provide details or an example that fails when using an AsBuilt INF? I would like to see if there is something that can be done quickly to resolve your specific issues.
I agree that tools that do not need to use sources should not fail or generate an error if the sources are not present. We can investigate this. I do suspect, as you do, that a common parser is involved, and that parse will need adjustments for tools that do not require sources.
Thanks,
Mike
From: Jim...@De... [mailto:Jim...@De...]
Sent: Thursday, July 17, 2014 9:02 AM
To: Kinney, Michael D
Cc: edk...@li...
Subject: RE: Building from Binaries
Thanks, Mike.
I understand that and have been down that road. Unfortunately, ACPI tables
and a couple of other "special" things foiled that approach for me.
In any case, I would still like to know why GenFds is looking for the presence
of source files, when it is supposed to assemble the binaries that have already
been built. This seems totally wrong.
Regards,
Jim
From: Kinney, Michael D [mailto:mic...@in...]
Sent: Thursday, July 17, 2014 10:38 AM
To: Dailey, Jim; edk...@li...<mailto:edk...@li...>
Subject: RE: Building from Binaries
Jim,
When you build from sources in EDK II, the binaries are generated and an AsBuilt INF is also generated in the build output directory. The AsBuilt INF does not list the sources and only lists the binaries. If you use the AsBuild INF in your FDF file, then GenFds will not see a [Sources] section.
Thanks,
Mike
From: Jim...@De...<mailto:Jim...@De...> [mailto:Jim...@De...]
Sent: Thursday, July 17, 2014 8:20 AM
To: edk...@li...<mailto:edk...@li...>
Subject: [edk2-buildtools] Building from Binaries
I want to be able to supply a directory tree having tools and binaries from
an already built EDK2 BIOS. This would be useful so that, for example, the
provider of a driver which is included in the BIOS can rebuild the BIOS with
newer or different versions of the driver for debug and/or development.
It seems that GenFds quits when it can't find the first source file listed
in the first INF in the first FV it encounters in the FDF:
Generate Region at Offset 0x0
Region Size = 0x470000
Region Name = FV
Generating FVMAIN_COMPACT FV
Generating FVMAIN FV
GenFds...
<drive>:\<path>\<INF file name>.inf(20): error 000E: File/directory not
found in workspace
<drive>:\<path>\<include file name>.h
NMAKE : fatal error U1077: 'GenFds' : return code '0xe'
Stop.
My question is, why does GenFds care about source files at all when its
"user manual" states:
The output of the first phase of an EDK II build (as defined in
the EDK II Build Specification) generates valid PE32/PE32+/Coff
image files. GenFds performs the second phase of the build process
during which consumes the images generated during the first phase,
using statements and rules defined in the FDF file to place the
PE32/PE32+/Coff images files into one or more EFI sections.
GenFds requiring the presence of source files seems like a defect in the way
the tool behaves or is described in the manual.
My guess is the problem stems from using "generic" code that not only parses
the FDF, but delves into the files it includes in a way that is not needed by
(and in this case is detrimental to the operation of) GenFds.
Can this be corrected?
Can you recommend a process to accomplish my goal of building strictly from
existing binary files?
Regards,
Jim
|
|
From: <Jim...@De...> - 2014-07-17 16:01:48
|
Thanks, Mike.
I understand that and have been down that road. Unfortunately, ACPI tables
and a couple of other "special" things foiled that approach for me.
In any case, I would still like to know why GenFds is looking for the presence
of source files, when it is supposed to assemble the binaries that have already
been built. This seems totally wrong.
Regards,
Jim
From: Kinney, Michael D [mailto:mic...@in...]
Sent: Thursday, July 17, 2014 10:38 AM
To: Dailey, Jim; edk...@li...
Subject: RE: Building from Binaries
Jim,
When you build from sources in EDK II, the binaries are generated and an AsBuilt INF is also generated in the build output directory. The AsBuilt INF does not list the sources and only lists the binaries. If you use the AsBuild INF in your FDF file, then GenFds will not see a [Sources] section.
Thanks,
Mike
From: Jim...@De...<mailto:Jim...@De...> [mailto:Jim...@De...]
Sent: Thursday, July 17, 2014 8:20 AM
To: edk...@li...<mailto:edk...@li...>
Subject: [edk2-buildtools] Building from Binaries
I want to be able to supply a directory tree having tools and binaries from
an already built EDK2 BIOS. This would be useful so that, for example, the
provider of a driver which is included in the BIOS can rebuild the BIOS with
newer or different versions of the driver for debug and/or development.
It seems that GenFds quits when it can't find the first source file listed
in the first INF in the first FV it encounters in the FDF:
Generate Region at Offset 0x0
Region Size = 0x470000
Region Name = FV
Generating FVMAIN_COMPACT FV
Generating FVMAIN FV
GenFds...
<drive>:\<path>\<INF file name>.inf(20): error 000E: File/directory not
found in workspace
<drive>:\<path>\<include file name>.h
NMAKE : fatal error U1077: 'GenFds' : return code '0xe'
Stop.
My question is, why does GenFds care about source files at all when its
"user manual" states:
The output of the first phase of an EDK II build (as defined in
the EDK II Build Specification) generates valid PE32/PE32+/Coff
image files. GenFds performs the second phase of the build process
during which consumes the images generated during the first phase,
using statements and rules defined in the FDF file to place the
PE32/PE32+/Coff images files into one or more EFI sections.
GenFds requiring the presence of source files seems like a defect in the way
the tool behaves or is described in the manual.
My guess is the problem stems from using "generic" code that not only parses
the FDF, but delves into the files it includes in a way that is not needed by
(and in this case is detrimental to the operation of) GenFds.
Can this be corrected?
Can you recommend a process to accomplish my goal of building strictly from
existing binary files?
Regards,
Jim
|
|
From: Kinney, M. D <mic...@in...> - 2014-07-17 15:49:28
|
Jim,
When you build from sources in EDK II, the binaries are generated and an AsBuilt INF is also generated in the build output directory. The AsBuilt INF does not list the sources and only lists the binaries. If you use the AsBuild INF in your FDF file, then GenFds will not see a [Sources] section.
Thanks,
Mike
From: Jim...@De... [mailto:Jim...@De...]
Sent: Thursday, July 17, 2014 8:20 AM
To: edk...@li...
Subject: [edk2-buildtools] Building from Binaries
I want to be able to supply a directory tree having tools and binaries from
an already built EDK2 BIOS. This would be useful so that, for example, the
provider of a driver which is included in the BIOS can rebuild the BIOS with
newer or different versions of the driver for debug and/or development.
It seems that GenFds quits when it can't find the first source file listed
in the first INF in the first FV it encounters in the FDF:
Generate Region at Offset 0x0
Region Size = 0x470000
Region Name = FV
Generating FVMAIN_COMPACT FV
Generating FVMAIN FV
GenFds...
<drive>:\<path>\<INF file name>.inf(20): error 000E: File/directory not
found in workspace
<drive>:\<path>\<include file name>.h
NMAKE : fatal error U1077: 'GenFds' : return code '0xe'
Stop.
My question is, why does GenFds care about source files at all when its
"user manual" states:
The output of the first phase of an EDK II build (as defined in
the EDK II Build Specification) generates valid PE32/PE32+/Coff
image files. GenFds performs the second phase of the build process
during which consumes the images generated during the first phase,
using statements and rules defined in the FDF file to place the
PE32/PE32+/Coff images files into one or more EFI sections.
GenFds requiring the presence of source files seems like a defect in the way
the tool behaves or is described in the manual.
My guess is the problem stems from using "generic" code that not only parses
the FDF, but delves into the files it includes in a way that is not needed by
(and in this case is detrimental to the operation of) GenFds.
Can this be corrected?
Can you recommend a process to accomplish my goal of building strictly from
existing binary files?
Regards,
Jim
|
|
From: <Jim...@De...> - 2014-07-17 15:20:22
|
I want to be able to supply a directory tree having tools and binaries from
an already built EDK2 BIOS. This would be useful so that, for example, the
provider of a driver which is included in the BIOS can rebuild the BIOS with
newer or different versions of the driver for debug and/or development.
It seems that GenFds quits when it can't find the first source file listed
in the first INF in the first FV it encounters in the FDF:
Generate Region at Offset 0x0
Region Size = 0x470000
Region Name = FV
Generating FVMAIN_COMPACT FV
Generating FVMAIN FV
GenFds...
<drive>:\<path>\<INF file name>.inf(20): error 000E: File/directory not
found in workspace
<drive>:\<path>\<include file name>.h
NMAKE : fatal error U1077: 'GenFds' : return code '0xe'
Stop.
My question is, why does GenFds care about source files at all when its
"user manual" states:
The output of the first phase of an EDK II build (as defined in
the EDK II Build Specification) generates valid PE32/PE32+/Coff
image files. GenFds performs the second phase of the build process
during which consumes the images generated during the first phase,
using statements and rules defined in the FDF file to place the
PE32/PE32+/Coff images files into one or more EFI sections.
GenFds requiring the presence of source files seems like a defect in the way
the tool behaves or is described in the manual.
My guess is the problem stems from using "generic" code that not only parses
the FDF, but delves into the files it includes in a way that is not needed by
(and in this case is detrimental to the operation of) GenFds.
Can this be corrected?
Can you recommend a process to accomplish my goal of building strictly from
existing binary files?
Regards,
Jim
|
|
From: Jarlstrom, L. <lau...@in...> - 2014-07-16 18:44:49
|
Please note that github does not work with IE 7 or 8. You will get an error message from that bowser Please note that GitHub no longer supports Internet Explorer versions 7 or 8. We recommend upgrading to the latest Internet Explorer<http://windows.microsoft.com/ie>, Google Chrome<https://chrome.google.com>, or Firefox<https://mozilla.org/firefox/>. If you are using IE 9 or later, make sure you turn off "Compatibility View"<http://windows.microsoft.com/en-US/windows7/webpages-look-incorrect-in-Internet-Explorer>. thanks, Laurie lau...@in...<mailto:lau...@in...> EFI / Framework Technical Marketing Engineering Team (503) 712-9395 From: Jarlstrom, Laurie [mailto:lau...@in...] Sent: Wednesday, July 16, 2014 11:27 AM To: edk...@li...; edk...@li... Subject: [edk2-buildtools] Tianocore.org wiki performance issues All, The github wiki pages http://tianocore.github.io/ have much better performance than the Sourceforge wiki pages. Please use the github link for now unless you find a link that is missing or not correct. There is a link on the main htttp://tianocore.org page to goto the github link. The Projects<https://github.com/tianocore/tianocore.github.io/wiki/Projects> link (on the upper right with Google Chrome) of the main github page can help you traverse through though the same links from the Sourceforge wiki pages. Meanwhile the Sourceforge mediawiki is still available and we will be maintaining a both for now. Thanks to Jordan for getting the github wiki up in place. thanks, Laurie lau...@in...<mailto:lau...@in...> EFI / Framework Technical Marketing Engineering Team (503) 712-9395 |
|
From: Jarlstrom, L. <lau...@in...> - 2014-07-16 18:27:27
|
All, The github wiki pages http://tianocore.github.io/ have much better performance than the Sourceforge wiki pages. Please use the github link for now unless you find a link that is missing or not correct. There is a link on the main htttp://tianocore.org page to goto the github link. The Projects<https://github.com/tianocore/tianocore.github.io/wiki/Projects> link (on the upper right with Google Chrome) of the main github page can help you traverse through though the same links from the Sourceforge wiki pages. Meanwhile the Sourceforge mediawiki is still available and we will be maintaining a both for now. Thanks to Jordan for getting the github wiki up in place. thanks, Laurie lau...@in...<mailto:lau...@in...> EFI / Framework Technical Marketing Engineering Team (503) 712-9395 |
|
From: Dong, E. <eri...@in...> - 2014-07-15 09:14:08
|
Aaron, As you have pointed, we can't use vfrStatementDefault to set the default value for the OrderedList statement, OrderedList can get default value through below method: 1. Through the EFI_BROWSER_ACTION_DEFAULT_STANDARD/EFI_BROWSER_ACTION_DEFAULT_MANUFACTURING callback. 2. Through the AltCfg String returned in the ExtractConfig function. 3. Through the order of the options nest in orderedlist statement. The priority from high to low, if driver get the default value from the high one, it will not try to get the default value again. Detail sample you can see the DriverSampleDxe driver in MdeModulePkg/Universal/DriverSampleDxe. Thanks, Eric From: Aaron Pop [mailto:aa...@am...] Sent: Monday, July 14, 2014 10:40 PM To: edk...@li... Subject: [edk2-buildtools] VfrCompile OrderedList I was hoping to receive some clarification about the VfrCompile's support of defaults for the OrderedList vfr statement. OrderedLists support the vfrStatementDefault grammer, but the vfrStatementDefault, through the vfrConstantValueField, only seems to support a Number/True/False/Time/Date/STRING_TOKEN. I don't see any support for a buffer type (EFI_IFR_TYPE_BUFFER), that would be required for supporting the ordering of values in the OrderedList statement. Is there another way to set a default ordering for the OrderedList statements? Thanks, Aaron The information contained in this message may be confidential and proprietary to American Megatrends, Inc. This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission. |
|
From: Andrew F. <af...@ap...> - 2014-07-14 22:37:02
|
On Jul 14, 2014, at 3:21 PM, Kinney, Michael D <mic...@in...> wrote: > Andrew, > > I think we can support all of these concepts. > > 1) SVN extern to binaries. Developer can opt-out of externs. > 2) Edksetup.* can be updated to detect if the binaries are already present or not. If they are not present, then edksetup.* can either build from sources or pull from source control. We need to add an extra parameter for edksetup.* to allow the developer to select either of these actions. > 3) Need to do some adjustment to existing BaseTools directory organization and build output directories, so scripts are always under source control, and binary tools for all operating systems are in consistent location that is compatible with base tools binaries sub-project. Don’t really need to do anything now. Can do this tasks if/when there are requests for additional OS specific tool binaries. > Mike, Thanks! I’m in Jordan’s camp, so I’d prefer to build the binaries. It would be a lot more convenient if edksetup.* would have an option to build the binaries. Some of the platforms end up getting built by scripts, and the scripts usually end up trying to figure out if the tools need to be built. Thus centralizing this logic in edksetup.sh would make it easier to construct and maintain the the scripts that control platform builds. So it would be nice if you could point to platform XYZ script and run it and it builds the tools, if needed, and the platform. > Thanks, > > Mike > > From: Andrew Fish [mailto:af...@ap...] > Sent: Monday, July 14, 2014 2:42 PM > To: Kinney, Michael D > Cc: edk...@li...; edk...@li... > Subject: Re: [edk2-buildtools] [edk2] [RFC] Proposal to retire edk2-buildtools sub-project > > > On Jul 14, 2014, at 2:11 PM, Kinney, Michael D <mic...@in...> wrote: > > > Andrew, > > The proposal here to have a sub-project for tool binaries is not limited to windows. We proposed a directory structure for the tool binaries that can support any number of operating systems. For operating systems where pulling binaries or build binaries is an option, we need to make it easy for each developer to make that choice. That is why I proposed using the SVN extern with the option to opt-out of the externs to avoid pulling the pre-built binaries. If we move that option into edksetp.*, then I am concerned that we will need to add an extra parameter to edksetup.* to pull or build from sources. I do not think we can auto-detect the developers intent here. > > > Mike, > > Sorry I did not realized more binaries would be included? Seems even more reason to only, optionally pull the ones you want… > > How is the BaseTools directory going to change to support this? Linux and OS X point to https://svn.code.sf.net/p/edk2/code/trunk/edk2/BaseTools/BinWrappers/PosixLike/. The scripts that wrap binaries all point to the same place ($EDK_TOOLS_PATH/Source/C/bin/$TOOL_BASENAME)? https://svn.code.sf.net/p/edk2/code/trunk/edk2/BaseTools/BinWrappers/PosixLike/GenFv. So basically today you can’t support multiple binary tools. > > Are you saying you are going to copy extra tools into the Bin directory? https://svn.code.sf.net/p/edk2/code/trunk/edk2/BaseTools/Bin/ > > If you look the current Bin directory for CYTGWIN you will see it is pointing to the common tools build output location. > > So it seems the tools build need a better concept of where to install the tools? > > I still like script building the tools, or copying them from source control as part of the install. > > > > For your question about the “previous plan”. Are you referring to how things work today? If you build BaseTools from sources under windows today, it will show file differences for the generated binaries. > > > I guess the current way, and the svn external. If you don’t pull the external I guess it is un-versioned. > > Thanks, > > Andrew Fish > > > Thanks, > > Mike > > From: Andrew Fish [mailto:af...@ap...] > Sent: Monday, July 14, 2014 12:21 PM > To: Kinney, Michael D > Cc: edk...@li...; edk...@li... > Subject: Re: [edk2-buildtools] [edk2] [RFC] Proposal to retire edk2-buildtools sub-project > > > On Jul 13, 2014, at 9:41 PM, Kinney, Michael D <mic...@in...> wrote: > > > > Andrew, > > The concept of pulling the binaries from svn if they are not present is a good option to consider. Maybe edksetup.bat pulls latest version of edk2-toolsbinaries sub-project if binaries are not present. This would require the command line version of svn to be installed and in the path for that to work. I am not sure if all SVN clients include command line utility or not. I will have to check. This is almost identical in behavior to proposed SVN extern. It just defers the pull of the binaries. > > I need to double check, but I believe the behavior when building tools would be as follows: > 1) If you use default (pull binaries) and build the tools, then yes, SVN will show file differences. > > Well for *.bat options make sense. For *.sh if you are not on Windows no point in pulling the binaries, and it is probably safe to kick off a build of the tools. I think the script (or the one it calls) already detects Cygwin vs. Linux vs. OS X, so it should not be that hard to do. > > > > 2) If you opt-out of binaries, then the binaries will be generated in a directory that is not under source control, so no file differences will be shown. > > > But what happens with the previous plan. It seems like if you build binaries you would get svn status notifications for all the binaries. > > > > Best regards, > > Mike > > From: Andrew Fish [mailto:af...@ap...] > Sent: Friday, July 11, 2014 5:19 PM > To: edk...@li... > Cc: edk...@li... > Subject: Re: [edk2-buildtools] [edk2] [RFC] Proposal to retire edk2-buildtools sub-project > > > On Jul 10, 2014, at 4:11 PM, Kinney, Michael D <mic...@in...> wrote: > > > > > Hello, > > I am looking for comments on a proposal on how EDK II BaseTools is maintained. The goal is to move all tool related development activities to the EDK II BaseTools. This is to address community feedback that there are long delays between changes made to the edk2-buildtools sub-project and the changes being propagated to EDK II BaseTools. There has also been feedback that some developers do not want the overhead of pulling Win32 binaries when they are not required. I am interested in your feedback (positive or negative) on this proposal and if you think steps should be added or removed or modified. > > I would appreciate feedback by 7/18/2014. Please let us know if you need more time to evaluate this proposal. > > Proposed steps: > =============== > 1) Create new sub-project for BaseTools binaries > a. SVN Link: https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/ > b. Status: Done. > 2) Intel to provide build server for BaseTools Win32 binaries > a. SVN Link: https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/Win32/ > b. Build Frequency: Once per day, but only if there are source changes since last build. > c. Build Time: 3 AM PDT > d. Build server to send email with build log when build is performed. > e. Build server send email that no build was required if no source changes since last build. > f. Status: In progress. Need a few more validation steps. > 3) Delete Win32 binaries from EDK II BaseTools and replace with an SVN extern. > a. Default will continue to pull Win32 binaries > b. Developers that do not want Win32 binaries can opt-out by ignoring externs. > c. Date: TBD. Goal is immediately after build server is stable. > > Mike, > > Given this complexity why don’t we just make edksetup.bat/edksetup.sh a little smarter. If edk2setup.* does not see the binaries it builds the tools. > > I guess on Windows there is a concern about having to install Python (I’m not sure if the Python Freeze is required if you have Python). So you could detect the tools where not installed, and pull down tool binaries via svn. You could have a file that con tainted the correct version of svn to pull for the tools. > > I like this as: > 1) Checking in binaries is evil, and not allowed in some production environments, so folks end up solving this problem anyway. > 2) It make the instructions for using the edk2setup.sh path easier. > > Thanks, > > Andrew Fish > > PS What happens to the svn external if some one builds tools locally? Does it show up as a modified file in svn? > > > > > > 4) Merge sources from Edk2-buildtools to EDK II BaseTools > a. Date: TBD. Goal is immediately after build server is stable. > 5) Change permissions on Edk2-buildtools sub-project to read-only and mark sub-project as inactive. > a. Date: TBD. Goal is immediately after EDK II BaseTools is synced with EDK2-buildtools. > 6) Retire edk...@li... mailing list. All commits to BaseTools sources will show up on edk...@li.... > 7) Retire edk...@li... and move all BaseTools related discussions to edk...@li... > > Thanks, > > Mike |
|
From: Kinney, M. D <mic...@in...> - 2014-07-14 22:22:17
|
Andrew, I think we can support all of these concepts. 1) SVN extern to binaries. Developer can opt-out of externs. 2) Edksetup.* can be updated to detect if the binaries are already present or not. If they are not present, then edksetup.* can either build from sources or pull from source control. We need to add an extra parameter for edksetup.* to allow the developer to select either of these actions. 3) Need to do some adjustment to existing BaseTools directory organization and build output directories, so scripts are always under source control, and binary tools for all operating systems are in consistent location that is compatible with base tools binaries sub-project. Don't really need to do anything now. Can do this tasks if/when there are requests for additional OS specific tool binaries. Thanks, Mike From: Andrew Fish [mailto:af...@ap...] Sent: Monday, July 14, 2014 2:42 PM To: Kinney, Michael D Cc: edk...@li...; edk...@li... Subject: Re: [edk2-buildtools] [edk2] [RFC] Proposal to retire edk2-buildtools sub-project On Jul 14, 2014, at 2:11 PM, Kinney, Michael D <mic...@in...<mailto:mic...@in...>> wrote: Andrew, The proposal here to have a sub-project for tool binaries is not limited to windows. We proposed a directory structure for the tool binaries that can support any number of operating systems. For operating systems where pulling binaries or build binaries is an option, we need to make it easy for each developer to make that choice. That is why I proposed using the SVN extern with the option to opt-out of the externs to avoid pulling the pre-built binaries. If we move that option into edksetp.*, then I am concerned that we will need to add an extra parameter to edksetup.* to pull or build from sources. I do not think we can auto-detect the developers intent here. Mike, Sorry I did not realized more binaries would be included? Seems even more reason to only, optionally pull the ones you want... How is the BaseTools directory going to change to support this? Linux and OS X point to https://svn.code.sf.net/p/edk2/code/trunk/edk2/BaseTools/BinWrappers/PosixLike/. The scripts that wrap binaries all point to the same place ($EDK_TOOLS_PATH/Source/C/bin/$TOOL_BASENAME)? https://svn.code.sf.net/p/edk2/code/trunk/edk2/BaseTools/BinWrappers/PosixLike/GenFv. So basically today you can't support multiple binary tools. Are you saying you are going to copy extra tools into the Bin directory? https://svn.code.sf.net/p/edk2/code/trunk/edk2/BaseTools/Bin/ If you look the current Bin directory for CYTGWIN you will see it is pointing to the common tools build output location. So it seems the tools build need a better concept of where to install the tools? I still like script building the tools, or copying them from source control as part of the install. For your question about the "previous plan". Are you referring to how things work today? If you build BaseTools from sources under windows today, it will show file differences for the generated binaries. I guess the current way, and the svn external. If you don't pull the external I guess it is un-versioned. Thanks, Andrew Fish Thanks, Mike From: Andrew Fish [mailto:af...@ap...] Sent: Monday, July 14, 2014 12:21 PM To: Kinney, Michael D Cc: edk...@li...<mailto:edk...@li...>; edk...@li...<mailto:edk...@li...> Subject: Re: [edk2-buildtools] [edk2] [RFC] Proposal to retire edk2-buildtools sub-project On Jul 13, 2014, at 9:41 PM, Kinney, Michael D <mic...@in...<mailto:mic...@in...>> wrote: Andrew, The concept of pulling the binaries from svn if they are not present is a good option to consider. Maybe edksetup.bat pulls latest version of edk2-toolsbinaries sub-project if binaries are not present. This would require the command line version of svn to be installed and in the path for that to work. I am not sure if all SVN clients include command line utility or not. I will have to check. This is almost identical in behavior to proposed SVN extern. It just defers the pull of the binaries. I need to double check, but I believe the behavior when building tools would be as follows: 1) If you use default (pull binaries) and build the tools, then yes, SVN will show file differences. Well for *.bat options make sense. For *.sh if you are not on Windows no point in pulling the binaries, and it is probably safe to kick off a build of the tools. I think the script (or the one it calls) already detects Cygwin vs. Linux vs. OS X, so it should not be that hard to do. 2) If you opt-out of binaries, then the binaries will be generated in a directory that is not under source control, so no file differences will be shown. But what happens with the previous plan. It seems like if you build binaries you would get svn status notifications for all the binaries. Best regards, Mike From: Andrew Fish [mailto:af...@ap...] Sent: Friday, July 11, 2014 5:19 PM To: edk...@li...<mailto:edk...@li...> Cc: edk...@li...<mailto:edk...@li...> Subject: Re: [edk2-buildtools] [edk2] [RFC] Proposal to retire edk2-buildtools sub-project On Jul 10, 2014, at 4:11 PM, Kinney, Michael D <mic...@in...<mailto:mic...@in...>> wrote: Hello, I am looking for comments on a proposal on how EDK II BaseTools is maintained. The goal is to move all tool related development activities to the EDK II BaseTools. This is to address community feedback that there are long delays between changes made to the edk2-buildtools sub-project and the changes being propagated to EDK II BaseTools. There has also been feedback that some developers do not want the overhead of pulling Win32 binaries when they are not required. I am interested in your feedback (positive or negative) on this proposal and if you think steps should be added or removed or modified. I would appreciate feedback by 7/18/2014. Please let us know if you need more time to evaluate this proposal. Proposed steps: =============== 1) Create new sub-project for BaseTools binaries a. SVN Link: https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/ b. Status: Done. 2) Intel to provide build server for BaseTools Win32 binaries a. SVN Link: https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/Win32/ b. Build Frequency: Once per day, but only if there are source changes since last build. c. Build Time: 3 AM PDT d. Build server to send email with build log when build is performed. e. Build server send email that no build was required if no source changes since last build. f. Status: In progress. Need a few more validation steps. 3) Delete Win32 binaries from EDK II BaseTools and replace with an SVN extern. a. Default will continue to pull Win32 binaries b. Developers that do not want Win32 binaries can opt-out by ignoring externs. c. Date: TBD. Goal is immediately after build server is stable. Mike, Given this complexity why don't we just make edksetup.bat/edksetup.sh a little smarter. If edk2setup.* does not see the binaries it builds the tools. I guess on Windows there is a concern about having to install Python (I'm not sure if the Python Freeze is required if you have Python). So you could detect the tools where not installed, and pull down tool binaries via svn. You could have a file that con tainted the correct version of svn to pull for the tools. I like this as: 1) Checking in binaries is evil, and not allowed in some production environments, so folks end up solving this problem anyway. 2) It make the instructions for using the edk2setup.sh path easier. Thanks, Andrew Fish PS What happens to the svn external if some one builds tools locally? Does it show up as a modified file in svn? 4) Merge sources from Edk2-buildtools to EDK II BaseTools a. Date: TBD. Goal is immediately after build server is stable. 5) Change permissions on Edk2-buildtools sub-project to read-only and mark sub-project as inactive. a. Date: TBD. Goal is immediately after EDK II BaseTools is synced with EDK2-buildtools. 6) Retire edk...@li...<mailto:edk...@li...> mailing list. All commits to BaseTools sources will show up on edk...@li...<mailto:edk...@li...>. 7) Retire edk...@li...<mailto:edk...@li...> and move all BaseTools related discussions to edk...@li...<mailto:edk...@li...> Thanks, Mike |
|
From: Kinney, M. D <mic...@in...> - 2014-07-14 22:14:54
|
Jordan, I have not seen any requests for additional binaries. I just want to make sure we do not make any design decisions that would preclude that if the request comes in later. Mike -----Original Message----- From: Jordan Justen [mailto:jlj...@gm...] Sent: Monday, July 14, 2014 2:42 PM To: Kinney, Michael D Cc: Andrew Fish; edk...@li...; edk...@li...; Paolo Bonzini Subject: Re: [edk2-buildtools] [edk2] [RFC] Proposal to retire edk2-buildtools sub-project On Mon, Jul 14, 2014 at 2:11 PM, Kinney, Michael D <mic...@in...> wrote: > Andrew, > > The proposal here to have a sub-project for tool binaries is not limited to > windows. We proposed a directory structure for the tool binaries that can > support any number of operating systems. For operating systems where > pulling binaries or build binaries is an option, we need to make it easy for > each developer to make that choice. That is why I proposed using the SVN > extern with the option to opt-out of the externs to avoid pulling the > pre-built binaries. If we move that option into edksetp.*, then I am > concerned that we will need to add an extra parameter to edksetup.* to pull > or build from sources. I do not think we can auto-detect the developers > intent here. And, how could this possibly work with externals? You can't select which externals to pull, so you have to decide whether to not download any binaries, or pull them all? I still don't see how these ideas are an improvement over my BaseToolsBins utility. Is there actually any desire for providing binaries other than Windows developers? I even think it is weird for Windows, but as long as it is outside of the EDK II source tree... If BaseTools binaries are going to be provided for Linux, I think Paolo has a better idea in that we should work to allow distros to package them. I expect most people are more comfortable running 'make -C BaseTools' rather than downloading binaries from someone other than their distro. -Jordan > For your question about the “previous plan”. Are you referring to how > things work today? If you build BaseTools from sources under windows today, > it will show file differences for the generated binaries. > > > > Thanks, > > > > Mike > > > > From: Andrew Fish [mailto:af...@ap...] > Sent: Monday, July 14, 2014 12:21 PM > To: Kinney, Michael D > Cc: edk...@li...; > edk...@li... > > > Subject: Re: [edk2-buildtools] [edk2] [RFC] Proposal to retire > edk2-buildtools sub-project > > > > > > On Jul 13, 2014, at 9:41 PM, Kinney, Michael D <mic...@in...> > wrote: > > > > Andrew, > > > > The concept of pulling the binaries from svn if they are not present is a > good option to consider. Maybe edksetup.bat pulls latest version of > edk2-toolsbinaries sub-project if binaries are not present. This would > require the command line version of svn to be installed and in the path for > that to work. I am not sure if all SVN clients include command line utility > or not. I will have to check. This is almost identical in behavior to > proposed SVN extern. It just defers the pull of the binaries. > > > > I need to double check, but I believe the behavior when building tools would > be as follows: > > 1) If you use default (pull binaries) and build the tools, then yes, > SVN will show file differences. > > > > Well for *.bat options make sense. For *.sh if you are not on Windows no > point in pulling the binaries, and it is probably safe to kick off a build > of the tools. I think the script (or the one it calls) already detects > Cygwin vs. Linux vs. OS X, so it should not be that hard to do. > > > > 2) If you opt-out of binaries, then the binaries will be generated in a > directory that is not under source control, so no file differences will be > shown. > > > > > > But what happens with the previous plan. It seems like if you build binaries > you would get svn status notifications for all the binaries. > > > > Best regards, > > > > Mike > > > > From: Andrew Fish [mailto:af...@ap...] > Sent: Friday, July 11, 2014 5:19 PM > To: edk...@li... > Cc: edk...@li... > Subject: Re: [edk2-buildtools] [edk2] [RFC] Proposal to retire > edk2-buildtools sub-project > > > > > > On Jul 10, 2014, at 4:11 PM, Kinney, Michael D <mic...@in...> > wrote: > > > > > Hello, > > I am looking for comments on a proposal on how EDK II BaseTools is > maintained. The goal is to move all tool related development activities to > the EDK II BaseTools. This is to address community feedback that there are > long delays between changes made to the edk2-buildtools sub-project and the > changes being propagated to EDK II BaseTools. There has also been feedback > that some developers do not want the overhead of pulling Win32 binaries when > they are not required. I am interested in your feedback (positive or > negative) on this proposal and if you think steps should be added or removed > or modified. > > I would appreciate feedback by 7/18/2014. Please let us know if you need > more time to evaluate this proposal. > > Proposed steps: > =============== > 1) Create new sub-project for BaseTools binaries > a. SVN Link: > https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/ > b. Status: Done. > 2) Intel to provide build server for BaseTools Win32 binaries > a. SVN Link: > https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/Win32/ > b. Build Frequency: Once per day, but only if there are > source changes since last build. > c. Build Time: 3 AM PDT > d. Build server to send email with build log when build is > performed. > e. Build server send email that no build was required if no > source changes since last build. > f. Status: In progress. Need a few more validation steps. > 3) Delete Win32 binaries from EDK II BaseTools and replace with an SVN > extern. > a. Default will continue to pull Win32 binaries > b. Developers that do not want Win32 binaries can opt-out by > ignoring externs. > c. Date: TBD. Goal is immediately after build server is > stable. > > > > Mike, > > > > Given this complexity why don’t we just make edksetup.bat/edksetup.sh a > little smarter. If edk2setup.* does not see the binaries it builds the > tools. > > > > I guess on Windows there is a concern about having to install Python (I’m > not sure if the Python Freeze is required if you have Python). So you could > detect the tools where not installed, and pull down tool binaries via svn. > You could have a file that con tainted the correct version of svn to pull > for the tools. > > > > I like this as: > > 1) Checking in binaries is evil, and not allowed in some production > environments, so folks end up solving this problem anyway. > > 2) It make the instructions for using the edk2setup.sh path easier. > > > > Thanks, > > > > Andrew Fish > > > > PS What happens to the svn external if some one builds tools locally? Does > it show up as a modified file in svn? > > > > > > > 4) Merge sources from Edk2-buildtools to EDK II BaseTools > a. Date: TBD. Goal is immediately after build server is > stable. > 5) Change permissions on Edk2-buildtools sub-project to read-only and mark > sub-project as inactive. > a. Date: TBD. Goal is immediately after EDK II BaseTools is > synced with EDK2-buildtools. > 6) Retire edk...@li... mailing list. All > commits to BaseTools sources will show up on > edk...@li.... > 7) Retire edk...@li... and move all BaseTools > related discussions to edk...@li... > > Thanks, > > Mike > > > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > edk2-buildtools-devel mailing list > edk...@li... > https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel > |
|
From: Andrew F. <af...@ap...> - 2014-07-14 21:42:00
|
On Jul 14, 2014, at 2:11 PM, Kinney, Michael D <mic...@in...> wrote: > Andrew, > > The proposal here to have a sub-project for tool binaries is not limited to windows. We proposed a directory structure for the tool binaries that can support any number of operating systems. For operating systems where pulling binaries or build binaries is an option, we need to make it easy for each developer to make that choice. That is why I proposed using the SVN extern with the option to opt-out of the externs to avoid pulling the pre-built binaries. If we move that option into edksetp.*, then I am concerned that we will need to add an extra parameter to edksetup.* to pull or build from sources. I do not think we can auto-detect the developers intent here. > Mike, Sorry I did not realized more binaries would be included? Seems even more reason to only, optionally pull the ones you want… How is the BaseTools directory going to change to support this? Linux and OS X point to https://svn.code.sf.net/p/edk2/code/trunk/edk2/BaseTools/BinWrappers/PosixLike/. The scripts that wrap binaries all point to the same place ($EDK_TOOLS_PATH/Source/C/bin/$TOOL_BASENAME)? https://svn.code.sf.net/p/edk2/code/trunk/edk2/BaseTools/BinWrappers/PosixLike/GenFv. So basically today you can’t support multiple binary tools. Are you saying you are going to copy extra tools into the Bin directory? https://svn.code.sf.net/p/edk2/code/trunk/edk2/BaseTools/Bin/ If you look the current Bin directory for CYTGWIN you will see it is pointing to the common tools build output location. So it seems the tools build need a better concept of where to install the tools? I still like script building the tools, or copying them from source control as part of the install. > For your question about the “previous plan”. Are you referring to how things work today? If you build BaseTools from sources under windows today, it will show file differences for the generated binaries. > I guess the current way, and the svn external. If you don’t pull the external I guess it is un-versioned. Thanks, Andrew Fish > Thanks, > > Mike > > From: Andrew Fish [mailto:af...@ap...] > Sent: Monday, July 14, 2014 12:21 PM > To: Kinney, Michael D > Cc: edk...@li...; edk...@li... > Subject: Re: [edk2-buildtools] [edk2] [RFC] Proposal to retire edk2-buildtools sub-project > > > On Jul 13, 2014, at 9:41 PM, Kinney, Michael D <mic...@in...> wrote: > > > Andrew, > > The concept of pulling the binaries from svn if they are not present is a good option to consider. Maybe edksetup.bat pulls latest version of edk2-toolsbinaries sub-project if binaries are not present. This would require the command line version of svn to be installed and in the path for that to work. I am not sure if all SVN clients include command line utility or not. I will have to check. This is almost identical in behavior to proposed SVN extern. It just defers the pull of the binaries. > > I need to double check, but I believe the behavior when building tools would be as follows: > 1) If you use default (pull binaries) and build the tools, then yes, SVN will show file differences. > > Well for *.bat options make sense. For *.sh if you are not on Windows no point in pulling the binaries, and it is probably safe to kick off a build of the tools. I think the script (or the one it calls) already detects Cygwin vs. Linux vs. OS X, so it should not be that hard to do. > > > 2) If you opt-out of binaries, then the binaries will be generated in a directory that is not under source control, so no file differences will be shown. > > > But what happens with the previous plan. It seems like if you build binaries you would get svn status notifications for all the binaries. > > > Best regards, > > Mike > > From: Andrew Fish [mailto:af...@ap...] > Sent: Friday, July 11, 2014 5:19 PM > To: edk...@li... > Cc: edk...@li... > Subject: Re: [edk2-buildtools] [edk2] [RFC] Proposal to retire edk2-buildtools sub-project > > > On Jul 10, 2014, at 4:11 PM, Kinney, Michael D <mic...@in...> wrote: > > > > Hello, > > I am looking for comments on a proposal on how EDK II BaseTools is maintained. The goal is to move all tool related development activities to the EDK II BaseTools. This is to address community feedback that there are long delays between changes made to the edk2-buildtools sub-project and the changes being propagated to EDK II BaseTools. There has also been feedback that some developers do not want the overhead of pulling Win32 binaries when they are not required. I am interested in your feedback (positive or negative) on this proposal and if you think steps should be added or removed or modified. > > I would appreciate feedback by 7/18/2014. Please let us know if you need more time to evaluate this proposal. > > Proposed steps: > =============== > 1) Create new sub-project for BaseTools binaries > a. SVN Link: https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/ > b. Status: Done. > 2) Intel to provide build server for BaseTools Win32 binaries > a. SVN Link: https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/Win32/ > b. Build Frequency: Once per day, but only if there are source changes since last build. > c. Build Time: 3 AM PDT > d. Build server to send email with build log when build is performed. > e. Build server send email that no build was required if no source changes since last build. > f. Status: In progress. Need a few more validation steps. > 3) Delete Win32 binaries from EDK II BaseTools and replace with an SVN extern. > a. Default will continue to pull Win32 binaries > b. Developers that do not want Win32 binaries can opt-out by ignoring externs. > c. Date: TBD. Goal is immediately after build server is stable. > > Mike, > > Given this complexity why don’t we just make edksetup.bat/edksetup.sh a little smarter. If edk2setup.* does not see the binaries it builds the tools. > > I guess on Windows there is a concern about having to install Python (I’m not sure if the Python Freeze is required if you have Python). So you could detect the tools where not installed, and pull down tool binaries via svn. You could have a file that con tainted the correct version of svn to pull for the tools. > > I like this as: > 1) Checking in binaries is evil, and not allowed in some production environments, so folks end up solving this problem anyway. > 2) It make the instructions for using the edk2setup.sh path easier. > > Thanks, > > Andrew Fish > > PS What happens to the svn external if some one builds tools locally? Does it show up as a modified file in svn? > > > > > 4) Merge sources from Edk2-buildtools to EDK II BaseTools > a. Date: TBD. Goal is immediately after build server is stable. > 5) Change permissions on Edk2-buildtools sub-project to read-only and mark sub-project as inactive. > a. Date: TBD. Goal is immediately after EDK II BaseTools is synced with EDK2-buildtools. > 6) Retire edk...@li... mailing list. All commits to BaseTools sources will show up on edk...@li.... > 7) Retire edk...@li... and move all BaseTools related discussions to edk...@li... > > Thanks, > > Mike |
|
From: Jordan J. <jlj...@gm...> - 2014-07-14 21:41:48
|
On Mon, Jul 14, 2014 at 2:11 PM, Kinney, Michael D <mic...@in...> wrote: > Andrew, > > The proposal here to have a sub-project for tool binaries is not limited to > windows. We proposed a directory structure for the tool binaries that can > support any number of operating systems. For operating systems where > pulling binaries or build binaries is an option, we need to make it easy for > each developer to make that choice. That is why I proposed using the SVN > extern with the option to opt-out of the externs to avoid pulling the > pre-built binaries. If we move that option into edksetp.*, then I am > concerned that we will need to add an extra parameter to edksetup.* to pull > or build from sources. I do not think we can auto-detect the developers > intent here. And, how could this possibly work with externals? You can't select which externals to pull, so you have to decide whether to not download any binaries, or pull them all? I still don't see how these ideas are an improvement over my BaseToolsBins utility. Is there actually any desire for providing binaries other than Windows developers? I even think it is weird for Windows, but as long as it is outside of the EDK II source tree... If BaseTools binaries are going to be provided for Linux, I think Paolo has a better idea in that we should work to allow distros to package them. I expect most people are more comfortable running 'make -C BaseTools' rather than downloading binaries from someone other than their distro. -Jordan > For your question about the “previous plan”. Are you referring to how > things work today? If you build BaseTools from sources under windows today, > it will show file differences for the generated binaries. > > > > Thanks, > > > > Mike > > > > From: Andrew Fish [mailto:af...@ap...] > Sent: Monday, July 14, 2014 12:21 PM > To: Kinney, Michael D > Cc: edk...@li...; > edk...@li... > > > Subject: Re: [edk2-buildtools] [edk2] [RFC] Proposal to retire > edk2-buildtools sub-project > > > > > > On Jul 13, 2014, at 9:41 PM, Kinney, Michael D <mic...@in...> > wrote: > > > > Andrew, > > > > The concept of pulling the binaries from svn if they are not present is a > good option to consider. Maybe edksetup.bat pulls latest version of > edk2-toolsbinaries sub-project if binaries are not present. This would > require the command line version of svn to be installed and in the path for > that to work. I am not sure if all SVN clients include command line utility > or not. I will have to check. This is almost identical in behavior to > proposed SVN extern. It just defers the pull of the binaries. > > > > I need to double check, but I believe the behavior when building tools would > be as follows: > > 1) If you use default (pull binaries) and build the tools, then yes, > SVN will show file differences. > > > > Well for *.bat options make sense. For *.sh if you are not on Windows no > point in pulling the binaries, and it is probably safe to kick off a build > of the tools. I think the script (or the one it calls) already detects > Cygwin vs. Linux vs. OS X, so it should not be that hard to do. > > > > 2) If you opt-out of binaries, then the binaries will be generated in a > directory that is not under source control, so no file differences will be > shown. > > > > > > But what happens with the previous plan. It seems like if you build binaries > you would get svn status notifications for all the binaries. > > > > Best regards, > > > > Mike > > > > From: Andrew Fish [mailto:af...@ap...] > Sent: Friday, July 11, 2014 5:19 PM > To: edk...@li... > Cc: edk...@li... > Subject: Re: [edk2-buildtools] [edk2] [RFC] Proposal to retire > edk2-buildtools sub-project > > > > > > On Jul 10, 2014, at 4:11 PM, Kinney, Michael D <mic...@in...> > wrote: > > > > > Hello, > > I am looking for comments on a proposal on how EDK II BaseTools is > maintained. The goal is to move all tool related development activities to > the EDK II BaseTools. This is to address community feedback that there are > long delays between changes made to the edk2-buildtools sub-project and the > changes being propagated to EDK II BaseTools. There has also been feedback > that some developers do not want the overhead of pulling Win32 binaries when > they are not required. I am interested in your feedback (positive or > negative) on this proposal and if you think steps should be added or removed > or modified. > > I would appreciate feedback by 7/18/2014. Please let us know if you need > more time to evaluate this proposal. > > Proposed steps: > =============== > 1) Create new sub-project for BaseTools binaries > a. SVN Link: > https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/ > b. Status: Done. > 2) Intel to provide build server for BaseTools Win32 binaries > a. SVN Link: > https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/Win32/ > b. Build Frequency: Once per day, but only if there are > source changes since last build. > c. Build Time: 3 AM PDT > d. Build server to send email with build log when build is > performed. > e. Build server send email that no build was required if no > source changes since last build. > f. Status: In progress. Need a few more validation steps. > 3) Delete Win32 binaries from EDK II BaseTools and replace with an SVN > extern. > a. Default will continue to pull Win32 binaries > b. Developers that do not want Win32 binaries can opt-out by > ignoring externs. > c. Date: TBD. Goal is immediately after build server is > stable. > > > > Mike, > > > > Given this complexity why don’t we just make edksetup.bat/edksetup.sh a > little smarter. If edk2setup.* does not see the binaries it builds the > tools. > > > > I guess on Windows there is a concern about having to install Python (I’m > not sure if the Python Freeze is required if you have Python). So you could > detect the tools where not installed, and pull down tool binaries via svn. > You could have a file that con tainted the correct version of svn to pull > for the tools. > > > > I like this as: > > 1) Checking in binaries is evil, and not allowed in some production > environments, so folks end up solving this problem anyway. > > 2) It make the instructions for using the edk2setup.sh path easier. > > > > Thanks, > > > > Andrew Fish > > > > PS What happens to the svn external if some one builds tools locally? Does > it show up as a modified file in svn? > > > > > > > 4) Merge sources from Edk2-buildtools to EDK II BaseTools > a. Date: TBD. Goal is immediately after build server is > stable. > 5) Change permissions on Edk2-buildtools sub-project to read-only and mark > sub-project as inactive. > a. Date: TBD. Goal is immediately after EDK II BaseTools is > synced with EDK2-buildtools. > 6) Retire edk...@li... mailing list. All > commits to BaseTools sources will show up on > edk...@li.... > 7) Retire edk...@li... and move all BaseTools > related discussions to edk...@li... > > Thanks, > > Mike > > > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > edk2-buildtools-devel mailing list > edk...@li... > https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel > |
|
From: Kinney, M. D <mic...@in...> - 2014-07-14 21:11:18
|
Andrew,
The proposal here to have a sub-project for tool binaries is not limited to windows. We proposed a directory structure for the tool binaries that can support any number of operating systems. For operating systems where pulling binaries or build binaries is an option, we need to make it easy for each developer to make that choice. That is why I proposed using the SVN extern with the option to opt-out of the externs to avoid pulling the pre-built binaries. If we move that option into edksetp.*, then I am concerned that we will need to add an extra parameter to edksetup.* to pull or build from sources. I do not think we can auto-detect the developers intent here.
For your question about the "previous plan". Are you referring to how things work today? If you build BaseTools from sources under windows today, it will show file differences for the generated binaries.
Thanks,
Mike
From: Andrew Fish [mailto:af...@ap...]
Sent: Monday, July 14, 2014 12:21 PM
To: Kinney, Michael D
Cc: edk...@li...; edk...@li...
Subject: Re: [edk2-buildtools] [edk2] [RFC] Proposal to retire edk2-buildtools sub-project
On Jul 13, 2014, at 9:41 PM, Kinney, Michael D <mic...@in...<mailto:mic...@in...>> wrote:
Andrew,
The concept of pulling the binaries from svn if they are not present is a good option to consider. Maybe edksetup.bat pulls latest version of edk2-toolsbinaries sub-project if binaries are not present. This would require the command line version of svn to be installed and in the path for that to work. I am not sure if all SVN clients include command line utility or not. I will have to check. This is almost identical in behavior to proposed SVN extern. It just defers the pull of the binaries.
I need to double check, but I believe the behavior when building tools would be as follows:
1) If you use default (pull binaries) and build the tools, then yes, SVN will show file differences.
Well for *.bat options make sense. For *.sh if you are not on Windows no point in pulling the binaries, and it is probably safe to kick off a build of the tools. I think the script (or the one it calls) already detects Cygwin vs. Linux vs. OS X, so it should not be that hard to do.
2) If you opt-out of binaries, then the binaries will be generated in a directory that is not under source control, so no file differences will be shown.
But what happens with the previous plan. It seems like if you build binaries you would get svn status notifications for all the binaries.
Best regards,
Mike
From: Andrew Fish [mailto:af...@ap...]
Sent: Friday, July 11, 2014 5:19 PM
To: edk...@li...<mailto:edk...@li...>
Cc: edk...@li...<mailto:edk...@li...>
Subject: Re: [edk2-buildtools] [edk2] [RFC] Proposal to retire edk2-buildtools sub-project
On Jul 10, 2014, at 4:11 PM, Kinney, Michael D <mic...@in...<mailto:mic...@in...>> wrote:
Hello,
I am looking for comments on a proposal on how EDK II BaseTools is maintained. The goal is to move all tool related development activities to the EDK II BaseTools. This is to address community feedback that there are long delays between changes made to the edk2-buildtools sub-project and the changes being propagated to EDK II BaseTools. There has also been feedback that some developers do not want the overhead of pulling Win32 binaries when they are not required. I am interested in your feedback (positive or negative) on this proposal and if you think steps should be added or removed or modified.
I would appreciate feedback by 7/18/2014. Please let us know if you need more time to evaluate this proposal.
Proposed steps:
===============
1) Create new sub-project for BaseTools binaries
a. SVN Link: https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/
b. Status: Done.
2) Intel to provide build server for BaseTools Win32 binaries
a. SVN Link: https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/Win32/
b. Build Frequency: Once per day, but only if there are source changes since last build.
c. Build Time: 3 AM PDT
d. Build server to send email with build log when build is performed.
e. Build server send email that no build was required if no source changes since last build.
f. Status: In progress. Need a few more validation steps.
3) Delete Win32 binaries from EDK II BaseTools and replace with an SVN extern.
a. Default will continue to pull Win32 binaries
b. Developers that do not want Win32 binaries can opt-out by ignoring externs.
c. Date: TBD. Goal is immediately after build server is stable.
Mike,
Given this complexity why don't we just make edksetup.bat/edksetup.sh a little smarter. If edk2setup.* does not see the binaries it builds the tools.
I guess on Windows there is a concern about having to install Python (I'm not sure if the Python Freeze is required if you have Python). So you could detect the tools where not installed, and pull down tool binaries via svn. You could have a file that con tainted the correct version of svn to pull for the tools.
I like this as:
1) Checking in binaries is evil, and not allowed in some production environments, so folks end up solving this problem anyway.
2) It make the instructions for using the edk2setup.sh path easier.
Thanks,
Andrew Fish
PS What happens to the svn external if some one builds tools locally? Does it show up as a modified file in svn?
4) Merge sources from Edk2-buildtools to EDK II BaseTools
a. Date: TBD. Goal is immediately after build server is stable.
5) Change permissions on Edk2-buildtools sub-project to read-only and mark sub-project as inactive.
a. Date: TBD. Goal is immediately after EDK II BaseTools is synced with EDK2-buildtools.
6) Retire edk...@li...<mailto:edk...@li...> mailing list. All commits to BaseTools sources will show up on edk...@li...<mailto:edk...@li...>.
7) Retire edk...@li...<mailto:edk...@li...> and move all BaseTools related discussions to edk...@li...<mailto:edk...@li...>
Thanks,
Mike
|
|
From: Andrew F. <af...@ap...> - 2014-07-14 19:22:38
|
On Jul 14, 2014, at 10:27 AM, Jordan Justen <jlj...@gm...> wrote: > On Sun, Jul 13, 2014 at 9:55 PM, Tian, Hot <hot...@in...> wrote: >> Defer the binary pull to build time is incompatible change. There may be >> cases that we don’t have network access when build the code. > > I guess I would consider this in the same bucket as not downloading > IASL before going offline. In other words, you better make sure your > build environment is setup before going offline or you might not be > able to build. > Yes I would advocate doing the edksetup.bat/edksetup.sh (Cygwin) activity prior to disconnecting from the network. It would be part of the download instructions. Thanks, Andrew Fish |
|
From: Andrew F. <af...@ap...> - 2014-07-14 19:21:24
|
On Jul 13, 2014, at 9:41 PM, Kinney, Michael D <mic...@in...> wrote: > Andrew, > > The concept of pulling the binaries from svn if they are not present is a good option to consider. Maybe edksetup.bat pulls latest version of edk2-toolsbinaries sub-project if binaries are not present. This would require the command line version of svn to be installed and in the path for that to work. I am not sure if all SVN clients include command line utility or not. I will have to check. This is almost identical in behavior to proposed SVN extern. It just defers the pull of the binaries. > > I need to double check, but I believe the behavior when building tools would be as follows: > 1) If you use default (pull binaries) and build the tools, then yes, SVN will show file differences. Well for *.bat options make sense. For *.sh if you are not on Windows no point in pulling the binaries, and it is probably safe to kick off a build of the tools. I think the script (or the one it calls) already detects Cygwin vs. Linux vs. OS X, so it should not be that hard to do. > 2) If you opt-out of binaries, then the binaries will be generated in a directory that is not under source control, so no file differences will be shown. > But what happens with the previous plan. It seems like if you build binaries you would get svn status notifications for all the binaries. > Best regards, > > Mike > > From: Andrew Fish [mailto:af...@ap...] > Sent: Friday, July 11, 2014 5:19 PM > To: edk...@li... > Cc: edk...@li... > Subject: Re: [edk2-buildtools] [edk2] [RFC] Proposal to retire edk2-buildtools sub-project > > > On Jul 10, 2014, at 4:11 PM, Kinney, Michael D <mic...@in...> wrote: > > > Hello, > > I am looking for comments on a proposal on how EDK II BaseTools is maintained. The goal is to move all tool related development activities to the EDK II BaseTools. This is to address community feedback that there are long delays between changes made to the edk2-buildtools sub-project and the changes being propagated to EDK II BaseTools. There has also been feedback that some developers do not want the overhead of pulling Win32 binaries when they are not required. I am interested in your feedback (positive or negative) on this proposal and if you think steps should be added or removed or modified. > > I would appreciate feedback by 7/18/2014. Please let us know if you need more time to evaluate this proposal. > > Proposed steps: > =============== > 1) Create new sub-project for BaseTools binaries > a. SVN Link: https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/ > b. Status: Done. > 2) Intel to provide build server for BaseTools Win32 binaries > a. SVN Link: https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/Win32/ > b. Build Frequency: Once per day, but only if there are source changes since last build. > c. Build Time: 3 AM PDT > d. Build server to send email with build log when build is performed. > e. Build server send email that no build was required if no source changes since last build. > f. Status: In progress. Need a few more validation steps. > 3) Delete Win32 binaries from EDK II BaseTools and replace with an SVN extern. > a. Default will continue to pull Win32 binaries > b. Developers that do not want Win32 binaries can opt-out by ignoring externs. > c. Date: TBD. Goal is immediately after build server is stable. > > Mike, > > Given this complexity why don’t we just make edksetup.bat/edksetup.sh a little smarter. If edk2setup.* does not see the binaries it builds the tools. > > I guess on Windows there is a concern about having to install Python (I’m not sure if the Python Freeze is required if you have Python). So you could detect the tools where not installed, and pull down tool binaries via svn. You could have a file that con tainted the correct version of svn to pull for the tools. > > I like this as: > 1) Checking in binaries is evil, and not allowed in some production environments, so folks end up solving this problem anyway. > 2) It make the instructions for using the edk2setup.sh path easier. > > Thanks, > > Andrew Fish > > PS What happens to the svn external if some one builds tools locally? Does it show up as a modified file in svn? > > > > 4) Merge sources from Edk2-buildtools to EDK II BaseTools > a. Date: TBD. Goal is immediately after build server is stable. > 5) Change permissions on Edk2-buildtools sub-project to read-only and mark sub-project as inactive. > a. Date: TBD. Goal is immediately after EDK II BaseTools is synced with EDK2-buildtools. > 6) Retire edk...@li... mailing list. All commits to BaseTools sources will show up on edk...@li.... > 7) Retire edk...@li... and move all BaseTools related discussions to edk...@li... > > Thanks, > > Mike |
|
From: Jordan J. <jlj...@gm...> - 2014-07-14 17:27:09
|
On Sun, Jul 13, 2014 at 9:55 PM, Tian, Hot <hot...@in...> wrote: > Defer the binary pull to build time is incompatible change. There may be > cases that we don’t have network access when build the code. I guess I would consider this in the same bucket as not downloading IASL before going offline. In other words, you better make sure your build environment is setup before going offline or you might not be able to build. Also, a project resisting moving to git worrying about working offline ... this is funny. :) -Jordan > From: Kinney, Michael D [mailto:mic...@in...] > Sent: Monday, July 14, 2014 12:42 > To: Andrew Fish; edk...@li... > > > Cc: edk...@li... > Subject: Re: [edk2-buildtools] [edk2] [RFC] Proposal to retire > edk2-buildtools sub-project > > > > Andrew, > > > > The concept of pulling the binaries from svn if they are not present is a > good option to consider. Maybe edksetup.bat pulls latest version of > edk2-toolsbinaries sub-project if binaries are not present. This would > require the command line version of svn to be installed and in the path for > that to work. I am not sure if all SVN clients include command line utility > or not. I will have to check. This is almost identical in behavior to > proposed SVN extern. It just defers the pull of the binaries. > > > > I need to double check, but I believe the behavior when building tools would > be as follows: > > 1) If you use default (pull binaries) and build the tools, then yes, > SVN will show file differences. > > 2) If you opt-out of binaries, then the binaries will be generated in a > directory that is not under source control, so no file differences will be > shown. > > > > Best regards, > > > > Mike > > > > From: Andrew Fish [mailto:af...@ap...] > Sent: Friday, July 11, 2014 5:19 PM > To: edk...@li... > Cc: edk...@li... > Subject: Re: [edk2-buildtools] [edk2] [RFC] Proposal to retire > edk2-buildtools sub-project > > > > > > On Jul 10, 2014, at 4:11 PM, Kinney, Michael D <mic...@in...> > wrote: > > > > Hello, > > I am looking for comments on a proposal on how EDK II BaseTools is > maintained. The goal is to move all tool related development activities to > the EDK II BaseTools. This is to address community feedback that there are > long delays between changes made to the edk2-buildtools sub-project and the > changes being propagated to EDK II BaseTools. There has also been feedback > that some developers do not want the overhead of pulling Win32 binaries when > they are not required. I am interested in your feedback (positive or > negative) on this proposal and if you think steps should be added or removed > or modified. > > I would appreciate feedback by 7/18/2014. Please let us know if you need > more time to evaluate this proposal. > > Proposed steps: > =============== > 1) Create new sub-project for BaseTools binaries > a. SVN Link: > https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/ > b. Status: Done. > 2) Intel to provide build server for BaseTools Win32 binaries > a. SVN Link: > https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/Win32/ > b. Build Frequency: Once per day, but only if there are > source changes since last build. > c. Build Time: 3 AM PDT > d. Build server to send email with build log when build is > performed. > e. Build server send email that no build was required if no > source changes since last build. > f. Status: In progress. Need a few more validation steps. > 3) Delete Win32 binaries from EDK II BaseTools and replace with an SVN > extern. > a. Default will continue to pull Win32 binaries > b. Developers that do not want Win32 binaries can opt-out by > ignoring externs. > c. Date: TBD. Goal is immediately after build server is > stable. > > > > Mike, > > > > Given this complexity why don’t we just make edksetup.bat/edksetup.sh a > little smarter. If edk2setup.* does not see the binaries it builds the > tools. > > > > I guess on Windows there is a concern about having to install Python (I’m > not sure if the Python Freeze is required if you have Python). So you could > detect the tools where not installed, and pull down tool binaries via svn. > You could have a file that con tainted the correct version of svn to pull > for the tools. > > > > I like this as: > > 1) Checking in binaries is evil, and not allowed in some production > environments, so folks end up solving this problem anyway. > > 2) It make the instructions for using the edk2setup.sh path easier. > > > > Thanks, > > > > Andrew Fish > > > > PS What happens to the svn external if some one builds tools locally? Does > it show up as a modified file in svn? > > > > > > 4) Merge sources from Edk2-buildtools to EDK II BaseTools > a. Date: TBD. Goal is immediately after build server is > stable. > 5) Change permissions on Edk2-buildtools sub-project to read-only and mark > sub-project as inactive. > a. Date: TBD. Goal is immediately after EDK II BaseTools is > synced with EDK2-buildtools. > 6) Retire edk...@li... mailing list. All > commits to BaseTools sources will show up on > edk...@li.... > 7) Retire edk...@li... and move all BaseTools > related discussions to edk...@li... > > Thanks, > > Mike > > > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck® > Code Sight™ - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > edk2-buildtools-devel mailing list > edk...@li... > https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel > |
|
From: Aaron P. <aa...@am...> - 2014-07-14 14:39:49
|
I was hoping to receive some clarification about the VfrCompile's support of defaults for the OrderedList vfr statement. OrderedLists support the vfrStatementDefault grammer, but the vfrStatementDefault, through the vfrConstantValueField, only seems to support a Number/True/False/Time/Date/STRING_TOKEN. I don't see any support for a buffer type (EFI_IFR_TYPE_BUFFER), that would be required for supporting the ordering of values in the OrderedList statement. Is there another way to set a default ordering for the OrderedList statements? Thanks, Aaron The information contained in this message may be confidential and proprietary to American Megatrends, Inc. This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission. |
|
From: Tian, H. <hot...@in...> - 2014-07-14 04:55:55
|
Defer the binary pull to build time is incompatible change. There may be cases that we don't have network access when build the code.
From: Kinney, Michael D [mailto:mic...@in...]
Sent: Monday, July 14, 2014 12:42
To: Andrew Fish; edk...@li...
Cc: edk...@li...
Subject: Re: [edk2-buildtools] [edk2] [RFC] Proposal to retire edk2-buildtools sub-project
Andrew,
The concept of pulling the binaries from svn if they are not present is a good option to consider. Maybe edksetup.bat pulls latest version of edk2-toolsbinaries sub-project if binaries are not present. This would require the command line version of svn to be installed and in the path for that to work. I am not sure if all SVN clients include command line utility or not. I will have to check. This is almost identical in behavior to proposed SVN extern. It just defers the pull of the binaries.
I need to double check, but I believe the behavior when building tools would be as follows:
1) If you use default (pull binaries) and build the tools, then yes, SVN will show file differences.
2) If you opt-out of binaries, then the binaries will be generated in a directory that is not under source control, so no file differences will be shown.
Best regards,
Mike
From: Andrew Fish [mailto:af...@ap...]
Sent: Friday, July 11, 2014 5:19 PM
To: edk...@li...<mailto:edk...@li...>
Cc: edk...@li...<mailto:edk...@li...>
Subject: Re: [edk2-buildtools] [edk2] [RFC] Proposal to retire edk2-buildtools sub-project
On Jul 10, 2014, at 4:11 PM, Kinney, Michael D <mic...@in...<mailto:mic...@in...>> wrote:
Hello,
I am looking for comments on a proposal on how EDK II BaseTools is maintained. The goal is to move all tool related development activities to the EDK II BaseTools. This is to address community feedback that there are long delays between changes made to the edk2-buildtools sub-project and the changes being propagated to EDK II BaseTools. There has also been feedback that some developers do not want the overhead of pulling Win32 binaries when they are not required. I am interested in your feedback (positive or negative) on this proposal and if you think steps should be added or removed or modified.
I would appreciate feedback by 7/18/2014. Please let us know if you need more time to evaluate this proposal.
Proposed steps:
===============
1) Create new sub-project for BaseTools binaries
a. SVN Link: https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/
b. Status: Done.
2) Intel to provide build server for BaseTools Win32 binaries
a. SVN Link: https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/Win32/
b. Build Frequency: Once per day, but only if there are source changes since last build.
c. Build Time: 3 AM PDT
d. Build server to send email with build log when build is performed.
e. Build server send email that no build was required if no source changes since last build.
f. Status: In progress. Need a few more validation steps.
3) Delete Win32 binaries from EDK II BaseTools and replace with an SVN extern.
a. Default will continue to pull Win32 binaries
b. Developers that do not want Win32 binaries can opt-out by ignoring externs.
c. Date: TBD. Goal is immediately after build server is stable.
Mike,
Given this complexity why don't we just make edksetup.bat/edksetup.sh a little smarter. If edk2setup.* does not see the binaries it builds the tools.
I guess on Windows there is a concern about having to install Python (I'm not sure if the Python Freeze is required if you have Python). So you could detect the tools where not installed, and pull down tool binaries via svn. You could have a file that con tainted the correct version of svn to pull for the tools.
I like this as:
1) Checking in binaries is evil, and not allowed in some production environments, so folks end up solving this problem anyway.
2) It make the instructions for using the edk2setup.sh path easier.
Thanks,
Andrew Fish
PS What happens to the svn external if some one builds tools locally? Does it show up as a modified file in svn?
4) Merge sources from Edk2-buildtools to EDK II BaseTools
a. Date: TBD. Goal is immediately after build server is stable.
5) Change permissions on Edk2-buildtools sub-project to read-only and mark sub-project as inactive.
a. Date: TBD. Goal is immediately after EDK II BaseTools is synced with EDK2-buildtools.
6) Retire edk...@li...<mailto:edk...@li...> mailing list. All commits to BaseTools sources will show up on edk...@li...<mailto:edk...@li...>.
7) Retire edk...@li...<mailto:edk...@li...> and move all BaseTools related discussions to edk...@li...<mailto:edk...@li...>
Thanks,
Mike
|
|
From: Kinney, M. D <mic...@in...> - 2014-07-14 04:42:17
|
Andrew,
The concept of pulling the binaries from svn if they are not present is a good option to consider. Maybe edksetup.bat pulls latest version of edk2-toolsbinaries sub-project if binaries are not present. This would require the command line version of svn to be installed and in the path for that to work. I am not sure if all SVN clients include command line utility or not. I will have to check. This is almost identical in behavior to proposed SVN extern. It just defers the pull of the binaries.
I need to double check, but I believe the behavior when building tools would be as follows:
1) If you use default (pull binaries) and build the tools, then yes, SVN will show file differences.
2) If you opt-out of binaries, then the binaries will be generated in a directory that is not under source control, so no file differences will be shown.
Best regards,
Mike
From: Andrew Fish [mailto:af...@ap...]
Sent: Friday, July 11, 2014 5:19 PM
To: edk...@li...
Cc: edk...@li...
Subject: Re: [edk2-buildtools] [edk2] [RFC] Proposal to retire edk2-buildtools sub-project
On Jul 10, 2014, at 4:11 PM, Kinney, Michael D <mic...@in...<mailto:mic...@in...>> wrote:
Hello,
I am looking for comments on a proposal on how EDK II BaseTools is maintained. The goal is to move all tool related development activities to the EDK II BaseTools. This is to address community feedback that there are long delays between changes made to the edk2-buildtools sub-project and the changes being propagated to EDK II BaseTools. There has also been feedback that some developers do not want the overhead of pulling Win32 binaries when they are not required. I am interested in your feedback (positive or negative) on this proposal and if you think steps should be added or removed or modified.
I would appreciate feedback by 7/18/2014. Please let us know if you need more time to evaluate this proposal.
Proposed steps:
===============
1) Create new sub-project for BaseTools binaries
a. SVN Link: https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/
b. Status: Done.
2) Intel to provide build server for BaseTools Win32 binaries
a. SVN Link: https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/Win32/
b. Build Frequency: Once per day, but only if there are source changes since last build.
c. Build Time: 3 AM PDT
d. Build server to send email with build log when build is performed.
e. Build server send email that no build was required if no source changes since last build.
f. Status: In progress. Need a few more validation steps.
3) Delete Win32 binaries from EDK II BaseTools and replace with an SVN extern.
a. Default will continue to pull Win32 binaries
b. Developers that do not want Win32 binaries can opt-out by ignoring externs.
c. Date: TBD. Goal is immediately after build server is stable.
Mike,
Given this complexity why don't we just make edksetup.bat/edksetup.sh a little smarter. If edk2setup.* does not see the binaries it builds the tools.
I guess on Windows there is a concern about having to install Python (I'm not sure if the Python Freeze is required if you have Python). So you could detect the tools where not installed, and pull down tool binaries via svn. You could have a file that con tainted the correct version of svn to pull for the tools.
I like this as:
1) Checking in binaries is evil, and not allowed in some production environments, so folks end up solving this problem anyway.
2) It make the instructions for using the edk2setup.sh path easier.
Thanks,
Andrew Fish
PS What happens to the svn external if some one builds tools locally? Does it show up as a modified file in svn?
4) Merge sources from Edk2-buildtools to EDK II BaseTools
a. Date: TBD. Goal is immediately after build server is stable.
5) Change permissions on Edk2-buildtools sub-project to read-only and mark sub-project as inactive.
a. Date: TBD. Goal is immediately after EDK II BaseTools is synced with EDK2-buildtools.
6) Retire edk...@li...<mailto:edk...@li...> mailing list. All commits to BaseTools sources will show up on edk...@li...<mailto:edk...@li...>.
7) Retire edk...@li...<mailto:edk...@li...> and move all BaseTools related discussions to edk...@li...<mailto:edk...@li...>
Thanks,
Mike
|
|
From: Andrew F. <af...@ap...> - 2014-07-12 00:19:31
|
On Jul 10, 2014, at 4:11 PM, Kinney, Michael D <mic...@in...> wrote: > Hello, > > I am looking for comments on a proposal on how EDK II BaseTools is maintained. The goal is to move all tool related development activities to the EDK II BaseTools. This is to address community feedback that there are long delays between changes made to the edk2-buildtools sub-project and the changes being propagated to EDK II BaseTools. There has also been feedback that some developers do not want the overhead of pulling Win32 binaries when they are not required. I am interested in your feedback (positive or negative) on this proposal and if you think steps should be added or removed or modified. > > I would appreciate feedback by 7/18/2014. Please let us know if you need more time to evaluate this proposal. > > Proposed steps: > =============== > 1) Create new sub-project for BaseTools binaries > a. SVN Link: https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/ > b. Status: Done. > 2) Intel to provide build server for BaseTools Win32 binaries > a. SVN Link: https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/Win32/ > b. Build Frequency: Once per day, but only if there are source changes since last build. > c. Build Time: 3 AM PDT > d. Build server to send email with build log when build is performed. > e. Build server send email that no build was required if no source changes since last build. > f. Status: In progress. Need a few more validation steps. > 3) Delete Win32 binaries from EDK II BaseTools and replace with an SVN extern. > a. Default will continue to pull Win32 binaries > b. Developers that do not want Win32 binaries can opt-out by ignoring externs. > c. Date: TBD. Goal is immediately after build server is stable. Mike, Given this complexity why don’t we just make edksetup.bat/edksetup.sh a little smarter. If edk2setup.* does not see the binaries it builds the tools. I guess on Windows there is a concern about having to install Python (I’m not sure if the Python Freeze is required if you have Python). So you could detect the tools where not installed, and pull down tool binaries via svn. You could have a file that con tainted the correct version of svn to pull for the tools. I like this as: 1) Checking in binaries is evil, and not allowed in some production environments, so folks end up solving this problem anyway. 2) It make the instructions for using the edk2setup.sh path easier. Thanks, Andrew Fish PS What happens to the svn external if some one builds tools locally? Does it show up as a modified file in svn? > 4) Merge sources from Edk2-buildtools to EDK II BaseTools > a. Date: TBD. Goal is immediately after build server is stable. > 5) Change permissions on Edk2-buildtools sub-project to read-only and mark sub-project as inactive. > a. Date: TBD. Goal is immediately after EDK II BaseTools is synced with EDK2-buildtools. > 6) Retire edk...@li... mailing list. All commits to BaseTools sources will show up on edk...@li.... > 7) Retire edk...@li... and move all BaseTools related discussions to edk...@li... > > Thanks, > > Mike |
|
From: Andrew F. <af...@ap...> - 2014-07-11 23:42:03
|
On Jul 11, 2014, at 4:23 PM, Laszlo Ersek <le...@re...> wrote: > And Jordan > explained to me that git had grown great support on Windows too, so it’s SourceTree is a good git GUI front end and it works on Windows 7+, and it is free. > not just for "Linux enthusiasts". (I of course assume that git works out > of the box on OS X.)) Yes it does. Thanks, Andrew Fish |
|
From: Laszlo E. <le...@re...> - 2014-07-11 23:23:25
|
On 07/12/14 00:53, Andrew Fish wrote: > > On Jul 10, 2014, at 4:11 PM, Kinney, Michael D > <mic...@in... <mailto:mic...@in...>> wrote: > >> Hello, >> >> I am looking for comments on a proposal on how EDK II BaseTools is >> maintained. The goal is to move all tool related development >> activities to the EDK II BaseTools. This is to address community >> feedback that there are long delays between changes made to the >> edk2-buildtools sub-project and the changes being propagated to EDK II >> BaseTools. There has also been feedback that some developers do not >> want the overhead of pulling Win32 binaries when they are not >> required. I am interested in your feedback (positive or negative) on >> this proposal and if you think steps should be added or removed or >> modified. >> >> I would appreciate feedback by 7/18/2014. Please let us know if you >> need more time to evaluate this proposal. >> >> Proposed steps: >> =============== >> 1) Create new sub-project for BaseTools binaries >> a. SVN Link: https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/ >> b. Status: Done. >> 2) Intel to provide build server for BaseTools Win32 binaries >> a. SVN Link: https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/Win32/ >> b. Build Frequency: Once per day, but only if there are source changes >> since last build. >> c. Build Time: 3 AM PDT >> d. Build server to send email with build log when build is performed. >> e. Build server send email that no build was required if no source >> changes since last build. >> f. Status: In progress. Need a few more validation steps. >> 3) Delete Win32 binaries from EDK II BaseTools and replace with an SVN >> extern. >> a. Default will continue to pull Win32 binaries >> b. Developers that do not want Win32 binaries can opt-out by ignoring >> externs. > > How does this work with a git mirror? Is it possible to setup an > officially supported git mirror for the svn? I guess the separate svn repo could be mirrored to a separate git repo, and then you could embed a new (== win32 binaries) git clone into your main (edk2) git clone (see git-submodule). (Since we're talking git anyway: in the near future we should simply abolish svn and use git exclusively; let's not forget that. I don't hold any malice against svn, but it's plain unsuitable for distributed development, its tooling is atrocious (for contributors, reviewers and maintainers alike), and it *shows*. Svn is *preventing* module maintainers from doing a good, careful job with patches. And Jordan explained to me that git had grown great support on Windows too, so it's not just for "Linux enthusiasts". (I of course assume that git works out of the box on OS X.)) Thanks Laszlo |
60 messages has been excluded from this view by a project administrator.
