On Feb 4, 2013, at 1:34 PM, "David F." <[email protected]> wrote:
The packages are also described by a packaging spec in XML. The build system parses text .DEC, .DSC, and .INF files that contain a subset of the information in the XML. So for example while the package manifest exists int he XML, it does not exist in the text files. > Hi, > > Still digging in to the build system and have a few questions/confirmations: > > Assuming I'm talking about a new package with a new component (app) created > by the driver wizard... > > 1) The .dsc file for the new testpkg contains [LibraryClasses] with a bunch > of (in the traditional sense) libraries. These libraries may or may not be > used by the various components added to the .dsc file. For convenience, the > driver wizard just added the "standard" set of libraries that EDK2 provides > for pure UEFI coding. Is all that correct? Assuming yes: > Yes. > A) Does having the items in [LibraryClasses] have anything to do with > building itself (with the exception of defining what libraries are available > for the components)? In other words, is it going to build all those > libraries at build time, or only if some component uses it? > The build processes the [Components] section and builds the dependency graph of what needs to built. So the [LibraryClasses] and [Pcd*] sections just for a data base of information that the build uses to figure out that to do for this build. It seems a little complex but one of the goals we had was to share code between PEI, DXE/EFI, and SMM (See PI Specification for more detail on these phases). In the EDK(previous code base) there were PEI libraries, and DXE/EFI Libraries, and SMM Libraries with different APIs. We wanted to just have a common library API to make it easier to move the code around. So that is why we have this library class concept. If you live in EFI space and don't know PEI, DXE, or SMM think of it like this. In each environment how you allocate memory is different, and what services are available to you are different, thus the code in the libraries need to be different. > B) The [components] section seems to be obvious in that is' similar to > adding a project to a solution in VS terminology or adding a target to a > project in other IDE type building systems? > Yes this is the set of modules (Application, Drivers, library instance, other) to build for the project. If you look at the https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdePkg/MdePkg.dsc you may notice that it also lists libraries in the [Components] section. This is just so all the libraries in the package can be built for all the supported processor architectures. This is just for testing the package. So some of the package .DSC files are not about building an application or platform firmware, they are about testing what is in the package. This can make things confusing if you don't realize this. > 2) The .dec file contains things like the default include paths, #defines, > but I'm confused on a couple issues still. > > A) Let's start with the [LibraryClasses] section. It looks like its > purpose is to define the .h file needed with a library class defined in the > .dsc file used elsewhere in a different package. Since only a fraction of > the files (looking in MdePkg) defined under [Components] in the .dsc file are > in [LibraryClasses] of the .dec file, is that basically declaring which of > the libraries are "public" or available to link with? Remember Library Class is an API definition. Library instance (mapping of [LibraryClasses] in .DSC file) is what you link against. The .INF file lists a Library Class and that Library Class must be defined in one the Packages the .INF file declares as a dependency. A library instance is just a module, as it is something that compiles. > And so some other component that would need a library would look to this > .dec file to know what's available to use in its [LibraryClasses] file? > (that's where we would find the libraries available to link with?) No linking means you have to find a module. So that means search for .INF files that have a LIBRARY_CLASS statement in the [Defines] section. That means this module is a library and it produces an instance of this library class. https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf > > B) the [Guids] Section - why is the GUID defined in the .dec file and in a > .h file? Is it a matter of discipline to create a .h file with a GUID > defined via #define and a variable GUID extern reference that will end up in > some .dec file? Seems like a lot of extra work? > Yes the #define is redundant. It is exists as this was the old style in the EDK. It is like you appendix. > 3) in the .INF file of say an application, what is the purpose of the items > in the [Packages] section? I mean, you already define which libraries > you're to use in [LibraryClasses] and the .dsc file points to how to build > that library (via an .inf file). The [Protocols] and [Guids] section are > what the build is going to consume/use and not what it's providing correct? > (basically the .inf file is a list of items used, not items being made > available) ?? > This is more of a workflow choice we made. We wanted to people to start a design and say what packages do I want to use. So the build will only scope looking for library classes, PCD, GUID, Protocol, PPI to the packages listed in the [Packages] section. For INF processing I guess it would be possible for the build system to give you a suggested package from your workspace an an error message. It would also be possible for the build system to give you a list of library instances that match the missing library class. > THANKS!! > > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_jan_______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
