Branch: refs/heads/master
Home: https://github.com/tianocore/edk2
Commit: 6511277827fd33023418e2ee72d6ab2b89a925f9
https://github.com/tianocore/edk2/commit/6511277827fd33023418e2ee72d6ab2b89a925f9
Author: Pierre Gondois <[email protected]>
Date: 2020-07-02 (Thu, 02 Jul 2020)
Changed paths:
M BaseTools/Source/Python/AutoGen/GenMake.py
M BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
Log Message:
-----------
BaseTools: Generate multiple rules when multiple output files
This patch modifies the Makefile generation not to stop
adding Makfile rules when the first final target is found.
E.g.:
If the following rules are described in build_rule.txt:
-[Rule1]: .X files generate .Y and .Z files;
-[Rule2]: .Z files generate .Z1 files.
Currently, if a File1.X file was part of the sources of a
module, only [Rule1] would be generated in the Makefile.
Indeed, there are no rules to apply to .Y files: .Y files
are a final target. However, there is still [Rule2] to
apply to .Z files.
This patch also adds a dependency between the first
ouput file of a rule and the other output files.
For instance, with the same example as above, File1.Y
and File1.Z are generated by the following rule:
File1.Y: File1.X
<Generate File1.Y>
<Generate File1.Z>
and the new dependency is:
File1.Z: File1.Y
This is necessary to keep a dependency order during the
execution of the Makefile. Indeed, .Y and .Z files are
generated by the execution of a common set of commands,
and without this rule, there is no explicit dependency
relation between them.
Signed-off-by: Pierre Gondois <[email protected]>
Suggested-by: Tomas Pilar <[email protected]>
Reviewed-by: Bob Feng <[email protected]>
Commit: 88228db38ead6836da7a8d24e11569d5fab54c54
https://github.com/tianocore/edk2/commit/88228db38ead6836da7a8d24e11569d5fab54c54
Author: Pierre Gondois <[email protected]>
Date: 2020-07-02 (Thu, 02 Jul 2020)
Changed paths:
A BaseTools/BinWrappers/PosixLike/AmlToC
R BaseTools/BinWrappers/PosixLike/AmlToHex
A BaseTools/BinWrappers/WindowsLike/AmlToC.bat
R BaseTools/BinWrappers/WindowsLike/AmlToHex.bat
A BaseTools/Source/Python/AmlToC/AmlToC.py
R BaseTools/Source/Python/AmlToHex/AmlToHex.py
Log Message:
-----------
BaseTools: Rename AmlToHex script to AmlToC
The AmlToHex script and Posix/WindowsLike wrappers convert
an AML file to a .hex file, containing a C array storing
AML bytecode. This ".hex" file can then be included in a
C file, allowing to access the AML bytecode from this C
file.
The EDK2 build system doesn't allow to a depict dependency
orders between files of different languages. For instance,
in a module containing a ".c" file and a ".asl", the ".c"
file may or may not be built prior to the ".asl" file.
This prevents any inclusion of a generated ".hex" in a
".c" file since this later ".hex" file may or may not
have been created yet.
This patch renames the script as AmlToC. It is posted as
a separate patch to prevent git from seeing the renaming
as a deletion plus addition of a new file.
The ending line of the posix-like bin-wrapper script has
also been corrected.
This is a first step toward generating a C file containing
the AML bytecode from an ASL file. This C file will then
be handled by the EDK2 build system to generate an object
file.
Thus, no file inclusion will be required anymore. The C file
requiring the AML bytecode as a C array, and the ASL file,
will be compiled independently. The C array must be defined
as an external symbol. The linker is resolving the
reference to the C array symbol.
To summarize, the flow goes as:
-1. ASL file is compiled to AML;
-2. AML file is copied to a ".amli" intermediate file;
-3. EDK2 build system applies the rule relevant to ".amli"
files. This is, calling the "AmlToC" script, generating
a C file from the ".amli" file;
-4. EDK2 build system applies the rule relevant to C files.
This is creating an object file.
-5. EDK2 build system links the object file containing the
AML bytecode with the object file requiring it.
Signed-off-by: Pierre Gondois <[email protected]>
Suggested-by: Tomas Pilar <[email protected]>
Reviewed-by: Bob Feng <[email protected]>
Commit: 0a4aa20e8d446c2f5dd54f3a0a7ec4d52f0ebdb6
https://github.com/tianocore/edk2/commit/0a4aa20e8d446c2f5dd54f3a0a7ec4d52f0ebdb6
Author: Pierre Gondois <[email protected]>
Date: 2020-07-02 (Thu, 02 Jul 2020)
Changed paths:
M BaseTools/Conf/build_rule.template
M BaseTools/Source/Python/AmlToC/AmlToC.py
Log Message:
-----------
BaseTools: Compile AML bytecode arrays into .obj file
The AmlToHex script and Posix/WindowsLike wrappers convert
an AML file to a .hex file, containing a C array storing
AML bytecode. This ".hex" file can then be included in a
C file, allowing to access the AML bytecode from this C
file.
The EDK2 build system doesn't allow to a depict dependency
orders between files of different languages. For instance,
in a module containing a ".c" file and a ".asl", the ".c"
file may or may not be built prior to the ".asl" file.
This prevents any inclusion of a generated ".hex" in a
".c" file since this later ".hex" file may or may not
have been created yet.
This patch modifies the AmlToC script to generate a C file
instead of a ".hex" file.
It also adds the generation of an intermediate ".amli" file
when compiling an ASL file, and adds a rule to convert this
".amli" to a C file.
This allows to generate a C file containing the AML bytecode
from an ASL file. This C file will then be handled by the EDK2
build system to generate an object file.
Thus, no file inclusion will be required anymore. The C file
requiring the AML bytecode as a C array, and the ASL file,
will be compiled independently. The C array must be defined
as an external symbol. The linker is resolving the
reference to the C array symbol.
To summarize, the flow goes as:
-1. ASL file is compiled to AML;
-2. AML file is copied to a ".amli" intermediate file;
-3. EDK2 build system applies the rule relevant to ".amli"
files. This is, calling the "AmlToC" script, generating
a C file from the ".amli" file;
-4. EDK2 build system applies the rule relevant to C files.
This is creating an object file.
-5. EDK2 build system links the object file containing the
AML bytecode with the object file requiring it.
Signed-off-by: Pierre Gondois <[email protected]>
Suggested-by: Tomas Pilar <[email protected]>
Reviewed-by: Bob Feng <[email protected]>
Commit: 0622a7b1b203ad4ab1675533e958792fc1afc12b
https://github.com/tianocore/edk2/commit/0622a7b1b203ad4ab1675533e958792fc1afc12b
Author: Pierre Gondois <[email protected]>
Date: 2020-07-02 (Thu, 02 Jul 2020)
Changed paths:
M BaseTools/Source/Python/AutoGen/BuildEngine.py
Log Message:
-----------
BaseTools: Fix string concatenation
Using Python 3.7.2 on win32, when printing a FileBuildRule
instance, the following error occurs:
File "edk2\BaseTools\Source\Python\AutoGen\BuildEngine.py",
line 177, in __str__
DestString = ", ".join(self.DestFileList)
TypeError: sequence item 0: expected str instance, PathClass found
This patch converts each PathClass element of the list to a string
instance before concatenating them.
Signed-off-by: Pierre Gondois <[email protected]>
Reviewed-by: Bob Feng <[email protected]>
Compare: https://github.com/tianocore/edk2/compare/01356d2963fc...0622a7b1b203
_______________________________________________
edk2-commits mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-commits
