mirror of https://github.com/acidanthera/audk.git
fb94f83131
https://bugzilla.tianocore.org/show_bug.cgi?id=1499 Compiler cache can greatly improve the build performance and guarantee the build result safe. In our testing, the compiler cache can improve the overall clean build time usually by 30+% in linux and 10+% in windows. The compiler cache are very fit to improve the Continuous Integration (CI) build performance. For linux compiler cache (ccache) enabling, there is no need to update edk2 code. Below link has the ccache enabling referencd steps: https://github.com/shijunjing/edk2/wiki/ Edk2-compiler-cache-enabling-steps-on-Linux For windows compiler cache (clcache) enabling, we need update the .PDB debugging file producing option from /Zi to /Z7, which is to let the C object file contain its full symbolic debugging information rather than produces a separated PDB file for all obj files per folder. "PDB files are generated by a different process (mspdbsrv). They arrive or are updated on disk after cl completes a compilation or linking operation. One huge problem with caching them is that the pdb files are input files as well as outputs. mspdbsrv updates the file with new debug information if the file exists beforehand. If there are several compilations going on at once targetting the same pdb then the order the pdb gets updated is unpredictable. All this makes caching very hard." The /Zi issue more detail disccusion can be found: https://github.com/frerich/clcache/issues/30 Please be aware that this change has no any impact to edk2 module level PDB file generation, and we still can get the PDB debug file for a .efi module. The /Z7 only impact intermediate obj files level PDB file, which is current one PDB file (vc140.pdb) per obj folder. Below link has the clcache enabling referencd steps: https://github.com/shijunjing/edk2/wiki/ Edk2-compiler-cache-enabling-steps-on-Windows Have tested below tools which consume the .PDB file: *Edk2 source code debugger *Various hardware and software debuggers *Uefi code coverage tools Only update and test below most commonly used four msvc toolchains: VS2012x86 VS2013x86 VS2015x86 VS2017 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Steven Shi <steven.shi@intel.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> |
||
---|---|---|
.. | ||
Bin | ||
BinWrappers | ||
Conf | ||
Scripts | ||
Source | ||
Tests | ||
UserManuals | ||
.gitignore | ||
BuildEnv | ||
GNUmakefile | ||
Makefile | ||
ReadMe.txt | ||
get_vsvars.bat | ||
set_vsprefix_envs.bat | ||
toolsetup.bat |
ReadMe.txt
This directory contains the next generation of EDK II build tools and template files. Templates are located in the Conf directory, while the tools executables for Microsoft Windows 32-bit Operating Systems are located in the Bin\Win32 directory, other directory contains tools source. 1. Build step to generate the binary tools. === Windows/Visual Studio Notes === To build the BaseTools, you should run the standard vsvars32.bat script from your preferred Visual Studio installation or you can run get_vsvars.bat to use latest automatically detected version. In addition to this, you should set the following environment variables: * EDK_TOOLS_PATH - Path to the BaseTools sub directory under the edk2 tree * BASE_TOOLS_PATH - The directory where the BaseTools source is located. (It is the same directory where this README.txt is located.) After this, you can run the toolsetup.bat file, which is in the same directory as this file. It should setup the remainder of the environment, and build the tools if necessary. Please also refer to the 'BuildNotes.txt' file for more information on building under Windows. === Unix-like operating systems === To build on Unix-like operating systems, you only need to type 'make' in the base directory of the project. === Ubuntu Notes === On Ubuntu, the following command should install all the necessary build packages to build all the C BaseTools: sudo apt-get install build-essential uuid-dev === Python sqlite3 module === On Windows, the cx_freeze will not copy the sqlite3.dll to the frozen binary directory (the same directory as build.exe and GenFds.exe). Please copy it manually from <PythonHome>\DLLs. The Python distributed with most recent Linux will have sqlite3 module built in. If not, please install sqlit3 package separately. 26-OCT-2011