]>
Commit | Line | Data |
---|---|---|
1 | This directory contains the next generation of EDK II build tools and template files.\r | |
2 | Templates are located in the Conf directory, while the tools executables for\r | |
3 | Microsoft Windows 32-bit Operating Systems are located in the Bin\Win32 directory, other \r | |
4 | directory contatins tools source.\r | |
5 | \r | |
6 | 1. Build step to generate the binary tools.\r | |
7 | \r | |
8 | === Windows/Visual Studio Notes ===\r | |
9 | \r | |
10 | To build the BaseTools, you should run the standard vsvars32.bat script.\r | |
11 | \r | |
12 | In addition to this, you should set the following environment variables:\r | |
13 | \r | |
14 | * EDK_TOOLS_PATH - Path to the BaseTools sub directory under the edk2 tree\r | |
15 | * BASE_TOOLS_PATH - The directory where the BaseTools source is located.\r | |
16 | (It is the same directory where this README.txt is located.)\r | |
17 | * PYTHON_FREEZER_PATH - Path to where the python freezer tool is installed\r | |
18 | \r | |
19 | After this, you can run the toolsetup.bat file, which is in the same\r | |
20 | directory as this file. It should setup the remainder of the environment,\r | |
21 | and build the tools if necessary.\r | |
22 | \r | |
23 | Please also refer to the 'BuildNotes.txt' file for more information on\r | |
24 | building under Windows.\r | |
25 | \r | |
26 | === Unix-like operating systems ===\r | |
27 | \r | |
28 | To build on Unix-like operating systems, you only need to type 'make' in\r | |
29 | the base directory of the project.\r | |
30 | \r | |
31 | === Ubuntu Notes ===\r | |
32 | \r | |
33 | On Ubuntu, the following command should install all the necessary build\r | |
34 | packages to build all the C BaseTools:\r | |
35 | \r | |
36 | sudo apt-get install build-essentials uuid-dev\r | |
37 | \r | |
38 | === Python sqlite3 module ===\r | |
39 | On Windows, the cx_freeze will not copy the sqlite3.dll to the frozen \r | |
40 | binary directory (the same directory as build.exe and GenFds.exe). \r | |
41 | Please copy it manually from <PythonHome>\DLLs.\r | |
42 | \r | |
43 | The Python distributed with most recent Linux will have sqlite3 module\r | |
44 | built in. If not, please install sqlit3 package separately.\r | |
45 | \r | |
46 | 2. The binary tools will be updated only after passing developer testing.\r | |
47 | \r | |
48 | Current state of the tools is Proto-Type - not all tool functions have been implemented\r | |
49 | and there may be bugs in these tools. These tools are under constant development at\r | |
50 | this time.\r | |
51 | \r | |
52 | 3. Tool usage introduction.\r | |
53 | BaseTools Simple Usage:\r | |
54 | 1) Change the directory to the EDK2 root directory, where the edksetup.bat is\r | |
55 | 2) Run "edksetup.bat NewBuild"\r | |
56 | 3) Set the ACTIVE_PLATFORM to your desired platform description file \r | |
57 | (%WORKSPACE%\Conf\target.txt)\r | |
58 | 4) To build platform, run "build" command in non-module directory\r | |
59 | 5) To build module individually, run "build" command in module directory, i.e. where the \r | |
60 | *.inf file is\r | |
61 | \r | |
62 | Notes:\r | |
63 | 1) The tree structure generated by build tools is similar to Ant build system.\r | |
64 | 2) Makefile can be called directly by nmake for both top level platform and module. But\r | |
65 | after you call "nmake cleanall", you have to call "build" command to rebuild platform\r | |
66 | or modules because the AutoGen.* files have been be removed. The "makefile" itself\r | |
67 | cannot generate AutoGen.* files. Only "build" command can.\r | |
68 | 3) All .exe binary file including C and python tools are generated from:\r | |
69 | r1911 <buildtools_project>\BaseTools\Source\.\r | |
70 | \r | |
71 | Brief usage for Migration Tool MigrationMsa2Inf.exe:\r | |
72 | 1. Command line format:\r | |
73 | MigrationMsa2Inf [options]\r | |
74 | 2. Input Files:\r | |
75 | A syntactically valid MSA file\r | |
76 | 3. Output Files:\r | |
77 | An extended INF file with possible auto-generated EntryPoint.c, CommonHeader.h/CommonHeader.txt, depending on options and module contents.\r | |
78 | 4. Prerequisite:\r | |
79 | a. The workspace directory must be specified either by environment variable or -w option. \r | |
80 | b. The Framework Database file must exist to specify the available packages in current workspace. \r | |
81 | Two possible locations are: (The first location overrides the second)\r | |
82 | $(WORKSPACE)\Tools\Conf\FrameworkDatabase.db\r | |
83 | $(WORKSPACE)\Conf\FrameworkDatabase.db. \r | |
84 | The <PackageList> field in FrameworkDatabase.db lists all available packages in current workspace. \r | |
85 | One example:\r | |
86 | <PackageList>\r | |
87 | <Filename>MdePkg/MdePkg.nspd</Filename>\r | |
88 | <Filename>MdeModulePkg/MdeModulePkg.spd</Filename>\r | |
89 | <Filename>IntelFrameworkPkg/IntelFrameworkPkg.spd</Filename>\r | |
90 | </PackageList>\r | |
91 | The package list in FrameworkDatabase.db is important to the final quality of migration:\r | |
92 | (1) It suggests the new package location: Translate package dependency Guid in MSA to Workspace relative path. \r | |
93 | If the package dependency Guid cannot be found in current workspace a warning message is raised. \r | |
94 | (2) It collects the Protocol/Guid/Ppi GuidCName a package contains. \r | |
95 | The GuidCName acts as "clue" to add e.g. #include <Protocol/DiskIo.h> in CommonHeader.h\r | |
96 | \r | |
97 | 5. Example:\r | |
98 | WORKSAPCE has already been set: $(WORKSPACE) = c:\work\EdkII. \r | |
99 | \r | |
100 | a. MigrationMsa2Inf -f c:\work\EdkII\Nt32Pkg\WinNtThunkDxe\WinNtThunk.msa -o c:\work\EdkII\Nt32Pkg\WinNtThunkDxe\WinNtThunk.inf\r | |
101 | b. MigrationMsa2Inf -f c:\work\EdkII\Nt32Pkg\WinNtThunkDxe\WinNtThunk.msa -a\r | |
102 | Example a & b are equivalent to migrate WinNtThunk driver from EDKII to EDKII' code base.\r | |
103 | \r | |
104 | c. MigrationMsa2Inf -f c:\work\EdkII\Nt32Pkg\WinNtThunkDxe\WinNtThunk.msa -a -c\r | |
105 | The extra "-c" option performs several hardcode mapping due to the naming change in EDKII': \r | |
106 | OldMdePkg Guid -> MdePkgGuid, \r | |
107 | EdkModulePkg Guid -> MdeModulePkgGuid, \r | |
108 | EdkGraphicsLib -> GraphicsLib\r | |
109 | HiiLib -> HiiLibFramework\r | |
110 | ...\r | |
111 | \r | |
112 | d. MigrationMsa2Inf -f c:\work\EdkII\Nt32Pkg\WinNtThunkDxe\WinNtThunk.msa -m\r | |
113 | The extra "-m" option suppresses the generation of "CommonHeader.h" and leave all C files intact. \r | |
114 | Instead, it generates "CommonHeader.txt". Developers can manually copy its content to a local common header file in a module. \r | |
115 | \r | |
116 | 6. Known Limitations:\r | |
117 | a. Tool does not handle Exit Boot Services Callback & Virtual Address Changed Event. Developers need to handle it manually.\r | |
118 | 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 | |
119 | c. The #include <Guid/Xyz.h>, <Protocol/Xyz.h> and <Ppi/Xyz.h> are added based on gGuidCName listed in MSA. \r | |
120 | If a GuidCName cannot map to a package Guid/Protocol/Ppi header file, a warning message is raised.\r | |
121 | 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 | |
122 | d. The [Depex] sections are generated from DXS files with Guid Macro translated to Guid CName by naming convention, etc.\r | |
123 | If tool fails to "guess" the Guid CName from Guid Macro, it will leave the GuidMacro in [Depex] section for manual resolution.\r | |
124 | e. When tool generates [Sources] section, the modifiers for source files are lost. (Need to add proper tool chain, etc)\r | |
125 | f. When tool generates [LibraryClasses] section, the recommended library instances are lost. (No impact to build)\r | |
126 | \r | |
127 | 7. Pyton Source\r | |
128 | BaseTools\Source\Python\MigrationMsa2Inf\r | |
129 | \r | |
130 | Brief usage for Migration Tool Spd2Dec.exe:\r | |
131 | 1. Command line format:\r | |
132 | Spd2Dec [options] input_filename\r | |
133 | 2. Input File:\r | |
134 | A syntactically valid SPD file\r | |
135 | 3. Output Files:\r | |
136 | A DEC file whose syntax confirms to DEC spec.\r | |
137 | \r | |
138 | 4. Example:\r | |
139 | a. Spd2Dec -o c:\work\EdkII\Nt32Pkg\Nt32.spd c:\work\EdkII\Nt32Pkg\Nt32.dec\r | |
140 | b. Spd2Dec -a c:\work\EdkII\Nt32Pkg\Nt32.spd\r | |
141 | Example a & b are equivalent to migrate Nt32 package SPD file from EDKII to EDKII' snytax.\r | |
142 | \r | |
143 | 6. Pyton Source\r | |
144 | BaseTools\Source\Python\spd2dec\r | |
145 | \r | |
146 | Brief usage for Migration Tool Fpd2Dsc.exe:\r | |
147 | 1. Command line format:\r | |
148 | Fpd2Dsc [options] input_filename\r | |
149 | 2. Input File:\r | |
150 | A syntactically valid FPD file\r | |
151 | 3. Output Files:\r | |
152 | A DSC file which syntax confirms to DSC spec.\r | |
153 | 4. Prerequisite:\r | |
154 | a. The workspace directory must be specified either by environment variable or -w option.\r | |
155 | \r | |
156 | 5. Example:\r | |
157 | WORKSAPCE has already been set: $(WORKSPACE) = c:\work\EdkII. \r | |
158 | \r | |
159 | a. Fpd2Dsc -o c:\work\EdkII\Nt32Pkg\Nt32.dsc c:\work\EdkII\Nt32Pkg\Nt32.fpd\r | |
160 | b. Fpd2Dsc -a c:\work\EdkII\Nt32Pkg\Nt32.fpd\r | |
161 | Example a & b are equivalent to migrate Nt32 platform description file from EDKII to EDKII' snytax.\r | |
162 | \r | |
163 | 6. Known Limitations:\r | |
164 | a. Tool does not handle Libraries Section since no related info in original FPD file. Developers need to handle it manually in the output DSC file.\r | |
165 | b. If MSA file which is corresponds to module guid could not be found in currect workspace, tool will dump the module guid.\r | |
166 | \r | |
167 | 7. Pyton Source\r | |
168 | BaseTools\Source\Python\fpd2dsc\r | |
169 | \r | |
170 | 4-Mar-2010\r |