On Jul 13, 2014, at 9:41 PM, Kinney, Michael D <[email protected]>
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:[email protected]]
> Sent: Friday, July 11, 2014 5:19 PM
> To: [email protected]
> Cc: [email protected]
> Subject: Re: [edk2-buildtools] [edk2] [RFC] Proposal to retire
> edk2-buildtools sub-project
>
>
> On Jul 10, 2014, at 4:11 PM, Kinney, Michael D <[email protected]>
> 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 [email protected] mailing list. All
> commits to BaseTools sources will show up on
> [email protected].
> 7) Retire [email protected] and move all BaseTools
> related discussions to [email protected]
>
> 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-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
