If I was receiving a binary from some vendor and an depex I would rather get the Depex in text form so I could modify it if needed. For example what if I only want to load the binary in certain circumstances? I might want to AND in a platform specific protocol that means load the binary driver.
I understand the basic issue: It is possible to inherit depex expressions from libraries so the INF file that built the binary driver does not contain the full depex. The build logs contain the correct information so this data could be sent in place of the binary depex file.
On Dec 5, 2012, at 12:03 PM, Hauch, Larry wrote:
You are correct in what the INF specification states. Unfortunately, this line was added accidentally.
As a future enhancement, we had planned on adding the depex statements in comments underneath the [Depex] section in the As Built INF file generated by the build system. We have not implemented the depex content in comments during As Built INF file generation yet.
So, for now, the paragraph should be remove from the INF specification.
I apologize for the confusion this may have caused.
The reason the build system does not re-generate the depex from [Depex] content in a Binary INF file is that it is assumed that the efi file was linked with specific library instances which may also have depex statements, so modifying any depex statements after the fact could result in an invalid driver that would be almost impossible to debug. It would require the binary module provider to ensure that every depex statement from every library instance linked against the module be ANDd with the depex statements from the driver not a simple task.
By listing the efi and depex files in the [Binaries] section, it was assumed that the binary depex was created at the same time that the efi module was linked (by the build system) and therefore included all required depex statements.
I will go further: The current .inf specification, section 3.14, says: For a binary INF file, the [Depex] sectionwill contain the full dependency expression, including the dependencies from the linked libraries. There is nothing in the spec which says that [Depex] is illegal in this case.
Thanks for your detailed response. What you say correctly describes the current behavior. Im asking why that behavior is desired, and suggesting that it is not desired. I believe there may be situations where you want a binary distributed driver, but a human-readable dependency expression.
Removing the python code I mentioned in my original message (ignoring [Depex] sections when only [Binaries] sections are present) allows a dependency section to be generated on the fly. An appropriate FDF statement will include the correct section.
I have some binary-only drivers with dependency expressions that are not being processed. These drivers are not UEFI model drivers.
I see in WorkspaceDatabase.py:
# If the module has only Binaries and no Sources, then ignore [Depex]
if self.Sources == None or self.Sources == :
if self.Binaries != None and self.Binaries != :
The intent being obvious from the comment (comes from SVN revision 2135 of edk2-buildtools repo). My question is, why are the [Depex] sections ignored from INFs with only binaries? I dont see in any of the EDKII documentation where this is stated. Is this a behavior that could be changed?