This directory contains the next generation of EDK II build tools and template files.\r
Templates are located in the Conf directory, while the tools executables for\r
-Microsoft Windows 32-bit Operating Systems are located in the Bin\Win32 directory.\r
+Microsoft Windows 32-bit Operating Systems are located in the Bin\Win32 directory, other \r
+directory contatins tools source.\r
\r
-The binary tools will be updated only after passing developer testing.\r
+1. Build step to generate the binary tools.\r
\r
-The BaseTools package will be updated with new tools only after all testing on a set\r
-of binary tools has successfully completed.\r
+=== Windows/Visual Studio Notes ===\r
\r
-Current state of the tools is Proto-Type - not all tool functions have been implemented\r
-and there may be bugs in these tools. These tools are under constant development at\r
-this time.\r
+To build the BaseTools, you should run the standard vsvars32.bat script\r
+from your preferred Visual Studio installation or you can run get_vsvars.bat\r
+to use latest automatically detected version.\r
\r
-BaseTools Simple Usage:\r
-1) Change the directory to the EDK2 root directory, where the edksetup.bat is\r
-2) Run "edksetup.bat NewBuild"\r
-3) Set the ACTIVE_PLATFORM to your desired platform description file \r
- (%WORKSPACE%\Conf\target.txt)\r
-4) To build platform, run "build" command in non-module directory\r
-5) To build module individually, run "build" command in module directory, i.e. where the \r
- *.inf file is\r
+In addition to this, you should set the following environment variables:\r
\r
-Notes:\r
-1) The tree structure generated by build tools is similar to Ant build system.\r
-2) Makefile can be called directly by nmake for both top level platform and module. But\r
- after you call "nmake cleanall", you have to call "build" command to rebuild platform\r
- or modules because the AutoGen.* files have been be removed. The "makefile" itself\r
- cannot generate AutoGen.* files. Only "build" command can.\r
-3) build.exe in %WORKSPACE%\BaseTools\Bin\Win32 is generated from following revision of\r
- Python source code:\r
- r658 <buildtools_project>\BaseTools\Source\Python\Autogen\r
- r723 <buildtools_project>\BaseTools\Source\Python\build\r
- r700 <buildtools_project>\BaseTools\Source\Python\Common\r
- r695 <buildtools_project>\BaseTools\Source\Python\CommonDataClass\r
- r710 <buildtools_project>\BaseTools\Source\Python\GenFds\r
- \r
-4) GenFds.exe has is a combo of the follow python source.(This is a temporary branch)\r
- r700 <buildtools_project>\BaseTools\Source\Python\Common\r
- r695 <buildtools_project>\BaseTools\Source\Python\CommonDataClass\r
- r710 <buildtools_project>\BaseTools\Source\Python\GenFds\r
- \r
-Brief usage for Migration Tool MigrationMsa2Inf.exe:\r
-1. Command line format:\r
- MigrationMsa2Inf [options]\r
-2. Input Files:\r
- A syntactically valid MSA file\r
-3. Output Files:\r
- An extended INF file with possible auto-generated EntryPoint.c, CommonHeader.h/CommonHeader.txt, depending on options and module contents.\r
-4. Prerequisite:\r
- a. The workspace directory must be specified either by environment variable or -w option. \r
- b. The Framework Database file must exist to specify the available packages in current workspace. \r
- Two possible locations are: (The first location overrides the second)\r
- $(WORKSPACE)\Tools\Conf\FrameworkDatabase.db\r
- $(WORKSPACE)\Conf\FrameworkDatabase.db. \r
- The <PackageList> field in FrameworkDatabase.db lists all available packages in current workspace. \r
- One example:\r
- <PackageList>\r
- <Filename>MdePkg/MdePkg.nspd</Filename>\r
- <Filename>MdeModulePkg/MdeModulePkg.spd</Filename>\r
- <Filename>IntelFrameworkPkg/IntelFrameworkPkg.spd</Filename>\r
- </PackageList>\r
- The package list in FrameworkDatabase.db is important to the final quality of migration:\r
- (1) It suggests the new package location: Translate package dependency Guid in MSA to Workspace relative path. \r
- If the package dependency Guid cannot be found in current workspace a warning message is raised. \r
- (2) It collects the Protocol/Guid/Ppi GuidCName a package contains. \r
- The GuidCName acts as "clue" to add e.g. #include <Protocol/DiskIo.h> in CommonHeader.h\r
- \r
-5. Example:\r
- WORKSAPCE has already been set: $(WORKSPACE) = c:\work\EdkII. \r
- \r
- a. MigrationMsa2Inf -f c:\work\EdkII\Nt32Pkg\WinNtThunkDxe\WinNtThunk.msa -o c:\work\EdkII\Nt32Pkg\WinNtThunkDxe\WinNtThunk.inf\r
- b. MigrationMsa2Inf -f c:\work\EdkII\Nt32Pkg\WinNtThunkDxe\WinNtThunk.msa -a\r
- Example a & b are equivalent to migrate WinNtThunk driver from EDKII to EDKII' code base.\r
- \r
- c. MigrationMsa2Inf -f c:\work\EdkII\Nt32Pkg\WinNtThunkDxe\WinNtThunk.msa -a -c\r
- The extra "-c" option performs several hardcode mapping due to the naming change in EDKII': \r
- OldMdePkg Guid -> MdePkgGuid, \r
- EdkModulePkg Guid -> MdeModulePkgGuid, \r
- EdkGraphicsLib -> GraphicsLib\r
- HiiLib -> HiiLibFramework\r
- ...\r
- \r
- d. MigrationMsa2Inf -f c:\work\EdkII\Nt32Pkg\WinNtThunkDxe\WinNtThunk.msa -m\r
- The extra "-m" option suppresses the generation of "CommonHeader.h" and leave all C files intact. \r
- Instead, it generates "CommonHeader.txt". Developers can manually copy its content to a local common header file in a module. \r
- \r
-6. Known Limitations:\r
- a. Tool does not handle Exit Boot Services Callback & Virtual Address Changed Event. Developers need to handle it manually.\r
- b. The #include <Library/AbcLib.h> is based on library class naming convention: The header filename for "AbcLib" class are "AbcLib.h" by convention.\r
- c. The #include <Guid/Xyz.h>, <Protocol/Xyz.h> and <Ppi/Xyz.h> are added based on gGuidCName listed in MSA. \r
- If a GuidCName cannot map to a package Guid/Protocol/Ppi header file, a warning message is raised.\r
- If a module uses the definition in a pakcage Guid/Protocol/Ppi header file without list its associative GuidCName, the build will beak. Developer needs to manually add the include statement.\r
- d. The [Depex] sections are generated from DXS files with Guid Macro translated to Guid CName by naming convention, etc.\r
- If tool fails to "guess" the Guid CName from Guid Macro, it will leave the GuidMacro in [Depex] section for manual resolution.\r
- e. When tool generates [Sources] section, the modifiers for source files are lost. (Need to add proper tool chain, etc)\r
- f. When tool generates [LibraryClasses] section, the recommended library instances are lost. (No impact to build)\r
- \r
-7. Pyton Source\r
- r682 <buildtools_project>\BaseTools\Source\Python\MigrationMsa2Inf\r
+ * EDK_TOOLS_PATH - Path to the BaseTools sub directory under the edk2 tree\r
+ * BASE_TOOLS_PATH - The directory where the BaseTools source is located.\r
+ (It is the same directory where this README.txt is located.)\r
+ * PYTHON_FREEZER_PATH - Path to where the python freezer tool is installed\r
\r
+After this, you can run the toolsetup.bat file, which is in the same\r
+directory as this file. It should setup the remainder of the environment,\r
+and build the tools if necessary.\r
\r
-Brief Usage for PcdSyntax Update:\r
-Usage:\r
- PcdSyntaxUpdate.exe <directory_name>\r
-It searches all INF, DEC and DSC file under <directory_name> and update them with the following rules:\r
-1. Update INF files to conform to INF spec 0.44: \r
- a. Rename PCD section name: e.g. [PcdsFeatureFlag] -> [FeaturePcd]\r
- b. Adjust PCD section item format: e.g. PcdDebugClearMemoryValue|gEfiMdePkgTokenSpaceGuid -> gEfiMdePkgTokenSpaceGuid.PcdDebugClearMemoryValue\r
- c. Update the syntax of binary INF file (not PCD related) \r
-2. Update DEC files to confirm to DEC spec 0.36\r
- Adjust PCD section item format: e.g. PcdWinNtPhysicalDisk|0x00001000|gEfiNt32PkgTokenSpaceGuid|VOID*|L"E:RW;245760;512"-> gEfiNt32PkgTokenSpaceGuid.PcdWinNtFlashFvRecoverySize|0x0|UINT32|0x00001011\r
-3. Update DSC files to confirm to DSC spec \r
- a. Adjust string/array typed PCD item format: e.g. PcdWinNtMemorySizeForSecMain|gEfiNt32PkgTokenSpaceGuid|L"64!64"|12 -> gEfiNt32PkgTokenSpaceGuid.PcdWinNtMemorySizeForSecMain|L"64!64"|VOID*|12\r
- b. Adjust non-string/array typed PCD item format: e.g. PcdWinNtBootMode|gEfiNt32PkgTokenSpaceGuid|1 -> gEfiNt32PkgTokenSpaceGuid.PcdWinNtBootMode|1\r
- c. Update the override library class in [Components] section: e.g.\r
- <LibraryClass> {\r
- PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf\r
- }\r
- To \r
- <LibraryClasses> {\r
- PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf\r
- }\r
+Please also refer to the 'BuildNotes.txt' file for more information on\r
+building under Windows.\r
\r
-30-August-2007\r
+=== Unix-like operating systems ===\r
+\r
+To build on Unix-like operating systems, you only need to type 'make' in\r
+the base directory of the project.\r
+\r
+=== Ubuntu Notes ===\r
+\r
+On Ubuntu, the following command should install all the necessary build\r
+packages to build all the C BaseTools:\r
+\r
+ sudo apt-get install build-essential uuid-dev\r
+\r
+=== Python sqlite3 module ===\r
+On Windows, the cx_freeze will not copy the sqlite3.dll to the frozen \r
+binary directory (the same directory as build.exe and GenFds.exe). \r
+Please copy it manually from <PythonHome>\DLLs.\r
+\r
+The Python distributed with most recent Linux will have sqlite3 module\r
+built in. If not, please install sqlit3 package separately.\r
+\r
+26-OCT-2011\r
projects / mirror_edk2.git / blobdiff