# 2.6 \[BuildOptions] Section Content in the `[BuildOptions]` section defines module specific tool chain flags that must be used as the default flags for a module. These flags are appended to any standard flags that are defined by the build process. In order to replace the standard flags that are defined by the build process, an alternate assignment operator must be used; "==" is used for replacement, while "=" is used to append the flag lines. Flags specified in this section can either be appended to the standard flags (defined in the `Conf/tools_def.txt`) or replace the standard flags. In addition to flags, other tool attributes may have the item either appended or replaced. The left side content of a statement may appear in both common and architectural sections. For example, `MSFT:DEBUG_*_*_CC_FLAGS` may be listed in a common section, while `MSFT:DEBUG_*_IA32_CC_FLAGS` may be listed in the architectural section. If the operator is a single "=" character, the flags from the architectural section are appended to the flags from the common section. Using this section may limit the ability of a module to be compiled with different tool chains or with different build systems and is therefore, discouraged. Valid content is within this section is limited to the following description. ### Table 2 EDK II \[BuildOptions] Section Elements | Tag | Value | Notes | | -------------------------------------------------------------------- | --------------------------------------------- | ------------------------------------------------------------------------------------------------ | | `${FAMILY}:${TARGET}_${TAGNAME}_` `${ARCH}_${TOOLCODE}_FLAGS` | Flags for specific tool codes for this module | Used to specify module specific flags of the module that will use the driver. | | `${FAMILY}:${TARGET}_${TAGNAME}_` `${ARCH}_${TOOLCODE}_PATH` | The fully qualified path an executable | Used to replace a specific command, such as forcing the ASL to be iasl, instead of asl. | | `${FAMILY}:${TARGET}_${TAGNAME}_` `${ARCH}_${TOOLCODE}_DPATH` | A fully qualified path | A path that will be added to the system Environment's PATH variable prior to executing a command | | `${FAMILY}:${TARGET}_${TAGNAME}_` `${ARCH}_${TOOLCODE}_${ATTRIBUTE}` | Attribute specific string | This permits overriding other attributes if required. | In this section, the following table describes each of the variables that are shown above. ### Table 3 EDK II \[BuildOptions] Variable Descriptions | Variable | Required | Wildcard | Source | | :---------: | :------: | :------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `FAMILY` | NO | No | `Conf/tools_def.txt` defines the `FAMILY` values, for example: `MSFT`, `INTEL` or `GCC`. Typically, this field is used to help the build tools determine whether the line is used for Microsoft style Makefiles or the GNU style Makefiles. | | | | | By not specifying the `FAMILY`, the tools assume the flags are applicable to all families. | | `TARGET` | YES | Yes = \* | `Conf/tools_def.txt` file defines two values: `DEBUG` and `RELEASE`. Developers may define additional targets. | | `TAGNAME` | YES | Yes = \* | `Conf/tools_def.txt` file defines several different tag names - these are defined by developers; the default tag name, `MYTOOLS`, is provided in the template for tools\_def.txt and set in the `Conf/target.txt` file. | | `ARCH` | YES | Yes = \* | `Conf/tools_def.txt` defines at least four architectures: `IA32`, `X64` and `EBC`. This tag must use all capital letters for the tag. Additional Architectures, such as PPC or ARM may be added as support becomes available. | | `TOOLCODE` | YES | NO | The tool code must be one of the defined tool codes in the `Conf/tools_def.txt` file. The flags defined in this section are appended to flags defined in the `tools_def.txt` file for individual tools. | | | | | EXCEPTION: If the INF `MODULE_TYPE`, defined in the `[Defines]` section is `USER_DEFINED` or `HOST_APPLICATION`, then the flags listed in this section are the only flags used for the TOOLCODE command specified in `Conf/ tools_def.txt`. | | `ATTRIBUTE` | YES | NO | The attribute must be specific to the tool code and must be a valid attribute handled by the build system. | Developers should use extreme caution when specifying items in this section. The EDK II build is designed to support multiple compilers and tool chains, expecting that code is written in ANSI C. If custom tool flags are required by a module, developers must make sure that all consumers of the module are aware of the specific tools and tag names required. **Note:** The lines are shown with the backslash "\\" character to indicate a line continuation, they are not allowed in the actual INF file. ``` [BuildOptions.common] MSFT:DEBUG_*_IA32_DLINK_FLAGS = /out:"$(BIN_DIR)SecMain.exe"/base:0x10000000 /pdb:"$(BIN_DIR)SecMain.pdb"/LIBPATH:"$(VCINSTALLDIR)Lib"/LIBPATH:"$(VCINSTALLDIR)PlatformSdkLib"/NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086/MAP /OPT:REF /DEBUG /MACHINE:I386 /LTCG Kernel32.lib MSVCRTD.lib Gdi32.lib User32.libWinmm.lib MSFT:DEBUG_*_IA32_CC_FLAGS = /nologo /W4 /WX /Gy /c /D UNICODE/D EFI32 /Od /DSTRING_ARRAY_NAME=SecMainStrings /FI$(DEST_DIR_DEBUG)/AutoGen.h /EHs-c- /GF /Gs8192/Zi /Gm ``` For `[BuildOptions]` sections in the INF file, the entries with a common left side (of the "=") will be either appended or replace previous entries based on the "==" replace or "=" append assignment character sequence. Sections with identical architecture modifiers are appended to each other. `Common Section + Architectural Section` ## Example: ``` [BuildOptions.Common] MSFT:*_*_*_CC_FLAGS = /nologo [BuildOptions.Common] MSFT:*_*_*_CC_FLAGS = /Od [BuildOptions.IA32] MSFT:*_*_IA32_CC_FLAGS = /D EFI32 ``` For IA32 architecture builds of an EDK II INF file would logically be: `MSFT:*_*_IA32_CC_FLAGS = /nologo /Od /D EFI32` For X64 architecture builds of an EDK II INF file would logically be: `MSFT:*_*_IA32_CC_FLAGS = /nologo /Od` --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://lersek.gitbook.io/laszlo-s-fork-of-the-edk-ii-module-information-inf/pkgs_order/2_inf_overview/26_-buildoptions-_section.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.