Menu
▾
▴
Re: [edk2-buildtools] [edk2] [RFC] Proposal to retire edk2-buildtools sub-project
|
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 > |
