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:[email protected]]
Sent: Monday, July 14, 2014 2:42 PM
To: Kinney, Michael D
Cc: [email protected];
[email protected]
Subject: Re: [edk2-buildtools] [edk2] [RFC] Proposal to retire edk2-buildtools
sub-project
On Jul 14, 2014, at 2:11 PM, Kinney, Michael D
<[email protected]<mailto:[email protected]>> 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:[email protected]]
Sent: Monday, July 14, 2014 12:21 PM
To: Kinney, Michael D
Cc: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: Re: [edk2-buildtools] [edk2] [RFC] Proposal to retire edk2-buildtools
sub-project
On Jul 13, 2014, at 9:41 PM, Kinney, Michael D
<[email protected]<mailto:[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]<mailto:[email protected]>
Cc:
[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>
mailing list. All commits to BaseTools sources will show up on
[email protected]<mailto:[email protected]>.
7) Retire
[email protected]<mailto:[email protected]>
and move all BaseTools related discussions to
[email protected]<mailto:[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
