Understanding the basic setup of .DCS, .DEC, and .INF build description files.

Please check for the latest version of the EDK II Specifications   == The .INF file:==  This file describes how to build a module (i.e. a driver, library, application, etc…).

    INF_VERSION            = 1.25

Defines the version of the EDK II INF specification the INF file supports.

     BASE_NAME             = NameOuputWithoutExtension

Defines the base output name of the module (application, library, etc...) when built resulting in the final .efi or .lib binary.

     FILE_GUID             = 11111111-2222-3333-4444-555555555555

A unique GUID for this module.

     MODULE_TYPE           = USER_DEFINED

The type of module being built. This includes things such as UEFI_DRIVER, UEFI_APPLICATION, DXE_DRIVER, etc… For libraries it can be BASE, USER_DEFINED, etc…

       VERSION_STRING      = 1.0

The version of your module.

       ENTRY_POINT         = MainFunctionName

If your module is not a library, this variable defines the function to begin execution. This is similar to the main() function in C.

       LIBRARY_CLASS  = LibNameToReference | AllowedModuleType1 AllowedModuleType2 Etc..

If your module is a library, this is the name the library is to be known as within the build system followed by a vertical bar and a list of space delimitated module types this library can be used with.

       CONSTRUCTOR         = LibInitializationFunction

If your module is a library and requires initialization on startup, you can use the CONSTRUCTOR variable to indicate the function name to call prior to a modules main entry point being called.

 

  List the various packages the module will use. This tells the build system where to look for library classes (header files for the library), PCDs, GUIDs, Protocols, and PPIs via the different packages .DEC files. The .DCS file from this package is not used.  

List the various source and header files used to build the module.

List the various libraries the module uses and should be linked with. This is the LibNameToReference value the library module used in its .INF file. For each entry in this section there needs to be an entry [LibraryClasses] sector of the .DCS file this module is associated with. This is because the packages in the [Packages] section are not used to determine the library module to link with.   For Example:

   LibNameToReference

 

  List the various protocol GUIDs variable name needed/used by the sources. The variable name is defined in one of the [Packages].DEC [Guids] section.  

  List the various GUIDs variable name needed/used by the sources. The variable name is defined in one of the [Packages].DEC [Guids] section.  

  Add compiler specific options needed to build the module.   

This file is used to declare what is available in the package and tells the build system where to find things such as “Include” directories. It can also be used to replace the use of #define values or constant variables in .h files though a mechanism called the Platform Configuration Database(PCD). This file is used when a module includes this package in its [Packages] section.  

       DEC_SPECIFICATION   = 1.25

Defines the version of the EDKII INF specification the INF file supports.

      PACKAGE_NAME         = NameOfThePackage
      PACKAGE_GUID         = 11111111-2222-3333-4444-555555555555
      PACKAGE_VERSION      = 1.00

This section lists the include directories for the package and modules that use the package (the search path for .h files). The [Incudes] section can also indicate directories by Architecture used by appending a period and architecture name to the Includes name. For example [Includes.IA32], [Includes.X64]. This is where your .C modules look for #include <header.h></header.h> files.   For example:

    TheIncludesDirectoryForThePackage

 

Lists the libraries available in (provided by) the package and where the header file can be found. The libraries available are the modules that belong to the package which are libraries. The name of the library available must match the LIBRARY_CLASS names given in the various .INF files that belong to the package. This is used by the build system when your modules .INF [Packages] section includes this package and its [LibraryClasses] include a LibNameToReference. The build system then generates the #include to the header file in the autogen.h file so you don’t need to include it in your source modules.   For example:

    LibNameToReference | relative/path/to/header.h  

 

Defines various GUIDS available / used by the package. It replaces #defines that would otherwise be in a .h file. However you still must define a .h file that includes an extern reference to the variable name.   For Example:

• note the ## comment below is recommended for documentation but not required by the build system.

    ##location/of/extern/header.h
    gSomeVarGuid = {0x11111111, 0x2222, 0x3333, {0x44, 0x44, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55}}

Now in a file /location/of/extern/header.h we add

    extern EFI_GUID gSomeVarGuid;

 

   [PcdsFeatureFlag]
   [PcdsFixedAtBuild]
   [PcdsFixedAtBuild,PcdsPatchableInModule]
   [PcdsDynamic,]

Etc…  These sections represent the creation of a Platform Configuration Database (PCD). Essentially this is a replacement for using #defines, #if defined, and static const variables in .h files. The desire of the designers of the EDK II was to discourage the use of #if define() type coding which could lead to code “rot” outside the defined areas. Instead it uses the compilers optimizations to strip the use of code not used. They also wanted to encourage the use of const variables over #defines where values may need to be patchable in binary form.  

This file describes how to build a package; a package being a set of components to be provided together.  

The values in this section are self-explanatory.

      PLATFORM_NAME            = name of the package
      PLATFORM_GUID            = 11111111-2222-3333-4444-555555555555
      PLATFORM_VERSION         = 1.00
      DSC_SPECIFICATION        = 1.26
      OUTPUT_DIRECTORY         = Build/packagedirectory
      SUPPORTED_ARCHITECTURES  = IA32|IPF|X64|EBC|ARM
      BUILD_TARGETS            = DEBUG|RELEASE
      SKUID_IDENTIFIER         = DEFAULT

 

List the various libraries the components of this package may use. This tells the build system where the library to link with is located. The modules .INF file indicates the LibNameToReference in its [LibraryClasses] section and the build system looks to this section for how to find it. The build system does not use your [Packages] section of the .INF to find the library to link with; it uses the [Packages] section to find the location of the header files for a library in a packages .DEC file. The format is:

    LibNameToReference|Path/To/Library/Inf/File.inf

    [PcdsFeatureFlag]
    [PcdsFixedAtBuild]
    [PcdsFixedAtBuild,PcdsPatchableInModule]
    [PcdsDynamic,]

Etc… These sections represent the redefinition of a particular token variable in the Platform Configuration Database (PCD). These are optional and only needed if the project needs a different value as defined in the .DEC file.  

List the various components or modules to build for this package specifically built as a result of when the package .DSC file is built; not when the package is referenced by the [Packages] section of an .INF file. You can also specify architecture specific sections by appending a period and architecture to the end of Components (e.g.[Components.IA32]). This section can also be used for building a library referenced in the [Packages] section of an .INF file.    This is used when you want to build a separate library and link to it in a traditional way or for debugging the library to ensure it builds properly.   For example:

• note that the relative path is from the edk2 svn base directory and not the package directory (also referred to as the Work Space Directory)

    relative/path/to/module.inf