REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2563
This patch is to fix a incremental build regression bug
which happen when using nmake. That's introduced by 818283de3f.
If there is white space before !INCLUDE instruction, nmake will not
process it. Source code's dependent header files are listed in
${deps_file} file, if it's not included successfully, nmake will
not detect the change of those header file.
This patch has been verified in Windows with VS2015 and Linux with GCC5.
The header file add/modify/delete can trig the incremental build with this fix.
There is no impact on the clean build.
Cc: Andrew Fish <afish@apple.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Tested-by: Liming Gao <liming.gao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2524
remove -DNO_MSABI_VA_FUNCS option in CLANGPDB tool chain After CLANGPDB is
switched to GNU mode, to use MS ABI version of GCC built-in macros for
variable argument lists as same as CLANG38 tool chain.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2520
Incremental build failure in CLANGPDB tool chain on Windows host
The build failure is like below when do incremental build.
The root cause is in generated deps_target file. It has one line ":".
Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2304
SyntaxWarning: "is" with a literal. Did you mean "=="?
Using "is" instead of "==" is an irregular syntax
Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com>
Cc: Bob C Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2142
gAdvancedFeaturePkgTokenSpaceGuid.PcdSmbiosType0BiosInformation|
{0x0}|SMBIOS_TABLE_TYPE0|0x80010000 {
<HeaderFiles>
IndustryStandard/SmBios.h
<Packages>
MdePkg/MdePkg.dec
AdvancedFeaturePkg/AdvancedFeaturePkg.dec
}
If there's a PcdStructHF or PcdStructPKGs in StructPcd,
EccTool report error,IndexError: list index out of range
This patch is going to fix this issue
Cc: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
NASM_INC contains the list of directory to include when using
the nasm assembler.
In nmake makefiles, a trailing backslash escapes the newline char
and replaces it with a space ' '. To have a literal trailing
backslash, it must be escaped with a caret '^'. This is not
necessary for GNU makefiles.
On windows platforms, for the NASM_INC macro, a caret escaping
a trailing a backslash was appended to the last included
folder regardless of the makefile type.
For instance, "/Include/" was replaced by "/Include/^\".
This is causing a build failure on windows platforms using
GNU makefiles since the caret '^' doesn't escape any chars in
GNU makefiles and is thus conserved.
"/Include^\" was replaced by "/Include\/" in nmake makefiles,
but remained "/Include/^\" in GNU makefiles.
This patch removes the caret '^' on the build using GNU makefiles.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
The GenMake.py script tests the platform environment
to determine the type of makefile that needs to be
generated. If a Windows build host is detected, the
makefile generated is of Nmake type. Otherwise a
GNUmake type is generated.
Furthermore, the <TARGET>_<TAGNAME>_<ARCH>_MAKE_PATH
option in tools_def.template defines the make tool
to use.
E.g.: for VS2017 this is configured to use Nmake, cf.
*_VS2017_*_MAKE_PATH = DEF(VS2017_BIN_HOST)\nmake.exe
while for GCC5 it is setup to use GNU make.
*_GCC5_*_MAKE_PATH = DEF(GCC_HOST_PREFIX)make
This prevents using the GCC compiler toolchain on a
Windows build host.
To address this issue this patch introduces 2 factors
to determine the generated makefile output.
1. Platform -> to determine shell commands used
in makefile.
2. MakeTool -> to determine the type of makefile
that needs to be generated.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
The .map file is not update to FFS_OUTPUT_DIR folder
in the incremental build.
Signed-off-by: Guo Dong <guo.dong@intel.com>
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=2505
Add plugin to BaseTools to run host based unit tests.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Bret Barkelew <Bret.Barkelew@microsoft.com>
Acked-by: Bob Feng <bob.c.feng@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=2496
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=2495
Update the WindowsVsToolChain plugin to setup the VS2017
or VS2019 development environment. This is required to
build BaseTools and Structured PCD host applications.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=2495
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=2496
Reduce the build and env dependencies for the Structured PCD
application by removing the dependency on Common.lib that
is only built when BaseTools is built which does not
happen if pre-compiled BaseToools are used. Change the
makefile for the Structure PCD application to build all
files from sources which adds PcdValueCommon.c to the
makefile. Also remove PcdValueCommon.c from Common.lib.
With the change to the makefile for the Structured PCD
application, multiple C files are compiled. Only
PcdValueInit.c contains the extra information expected
by the error/warning message parser. Only parse the
DSC line number into an error message if there is an
error/warning in PcdValueInit.c. Errors/warnings in
other files should be passed through. This fixes a build
failure with no useful log information that was observed
when there was a compiler error in PcdValueCommon.c.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2487
The call stack unwindability of the COFF X64 binary requires
the binary to remain the pdata and xdata sections.
Details see the MSVC X64 calling convertion doc in below link:
https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention
Current build options discard or zero the data in pdata and xdata
sections which cause the debugger cannot correctly unwind the
X64 binary call stack in the runtime.
Enhance the build options to force emit the unwind tables and
keep the data of pdata and xdata sections correct in the binary.
Signed-off-by: Steven Shi <steven.shi@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2502
This option is required to make GCC49 tool chain work with the high
version GCC compiler.
Cc: Bob Feng <bob.c.feng@intel.com>
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
The "-tc" option of the iasl compiler allows to generate a
.hex file containing a C array storing AML bytecode.
An online discussion suggested that this "-tc" option
was specific to the iasl compiler and it shouldn't be relied
on. This conversation is available at:
https://edk2.groups.io/g/devel/topic/39786201#49659
A way to address this issue is to implement a compiler
independent script that takes an AML file as input, and
generates a .hex file.
This patch implements a Python script that converts an AML
file to a .hex file, containing a C array storing AML bytecode.
This scipt has been tested with the AML output from the
following compilers supported by the EDKII implementation:
* Intel ASL compiler
* Microsoft ASL compiler
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
We check the author/committer name/email are properly displayed
since commits 8ffa47fb3ab..c0328cf3803. However if PatchCheck.py
uses the mailmap, it will check sanitized names/emails.
Use the --no-use-mailmap option so PatchCheck.py will check
unsanitized input.
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Due to strict DMARC / DKIM / SPF rules, Groups.Io sometimes rewrite
the author email. See for example commit df851da3ce.
Add a check to detect these rewrites with PatchCheck.py.
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
We added .mailmap to the repository in commit 4a1aeca3bd
to display commit mistakes fixed. Use this option by default in our
git setup.
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=2494
When using structured PCDs, a C application is auto generated
to fill in the structured PCD value. The C application uses
the standard include files <stdio.h>, <stdlib.h>, and <string.h>.
This C application also supports include paths from package DEC
files when a structured PCD declaration provides a <Packages>
list. The complete list of include paths are -I options for
include paths from package DEC files and the compiler's standard
include paths.
-I include paths are higher priority than the standard include
paths. If the -I included paths from package DEC files contain
<stdio.h>, <stdlib.h>, or <string.h> the wrong include files are
used to compile the C application for the structured PCD value.
Update GenerateByteArrayValue() to skip a package DEC include
paths that contain <stdio.h>, <stdlib.h>, or <string.h>.
Build failures were observed when adding a structured PCD to
CryptoPkg. CryptoPkg contains <stdio.h>, <stdlib.h>, and
<string.h> in the path CryptoPkg/Library/Include to support
building Open SSL. The Library/Include path is listed as a
private include path in CryptoPkg.dec. Without this change, the
standard include files designed to support build OpenSLL are
used to build the structured PCD C application, and that build
fails.
Other packages that provide a standard C lib or a gasket for
a subset of the standard C lib will run into this same issue
if they also define and use a Structured PCD. So this issue
is not limited to the CryptoPkg.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
The "--function-context" ("-W") option of git-diff displays the entire
body of a modified function, not just small modified hunks within the
function. It is useful for reviewers when the code changes to the function
are small, but they could affect, or depend on, control flow that is far
away in the same function.
Of course, the size of the displayed context can be controlled with the
"-U" option anyway, but such fixed-size contexts are usually either too
small, or too large, in the above scenario.
It turns out that "--function-context" does not work correctly for C
source files in edk2. In particular, labels for the goto instruction
(which the edk2 coding style places in the leftmost column) appear to
terminate "--function-context".
The "git" utility contains built-in hunk header patterns for the C and C++
languages. However, they do not take effect in edk2 because we don't
explicitly assign the "cpp" git-diff driver to our C files. The
gitattributes(5) manual explains that this is required:
> There are a few built-in patterns to make this easier, and
> tex is one of them, so you do not have to write the above in
> your configuration file (you still need to enable this with
> the attribute mechanism, via .gitattributes). The following
> built in patterns are available:
>
> [...]
>
> * cpp suitable for source code in the C and C++
> languages.
The key statement is the one in parentheses.
Grab the suffix lists from the [C-Code-File] and [Acpi-Table-Code-File]
sections of "BaseTools/Conf/build_rule.template", add "*.h" and "*.H", and
mark those as belonging to the "cpp" git-diff driver.
This change has a dramatic effect on the following command, for example:
$ git show -W 2ef0c27cb8
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200120094245.9010-1-lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=2484https://bugzilla.tianocore.org/show_bug.cgi?id=2485
Update PatchCheck to not enforce no tabs and not enforce CR/LF
line endings for .gitmodules files. These files are updated by
git when a git submodule command is used and the updates by git
use tab characters and LF line endings.
Also update patch check to not enforce CR/LF line endings for
patch lines that create a submodule directory. These patch
lines use LF line endings. The git submodule directory is
added as a new file with attributes 160000 that can be detected
by looking for the pattern "new file mode 160000".
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2451
If removing a header file from source code and file
system, the incremental build will fail.
This patch is to fix this issue by setting each header file
as a target without any actions in makefile.
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=2406
* Always print subject line after the git commit id to make
it easier to know the context of warnings or errors.
* Allow UTF-8 characters in subject line
* Error if subject line length > 75 without CVE-xxx-xxxxx present
* Error if subject line length > 92 with CVE-xxxx-xxxxx present
* If body line length is > 75, then print warning instead of error.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2455
BuildOption is used by TargetTxtClassObj.py
GenFdsOption is used by GenFds.py
When the GenFds tool is used alone (e.g. python3 -m GenFds.GenFds -h)
With the OptionParser function, the first detected function
prints the help message
import TargetTxtClassObj to GenFds,
The BuildOption will be executed and replace GenFdsOption
We removed all objects associated with this problem that
were created directly during the import process
(e.g. BuildOption, BuildTarget = MyOptionParser(),
TargetTxt = TargetTxtDict())
The Patch is going to fix this issue
Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2087
In CryptHkdf.c line 42
EVP_PKEY_CTX *pHkdfCtx;
Variable pHkdfCtx begins with lower case 'p',
which should be acceptable because it it is a pointer.
(Refer to CCS_2_1_Draft, 4.3.3.3)
So ECC tool should be improved to handle issues like this.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com>
To avoid patches committed with incorrect email address,
use the EmailAddressCheck class on the author email too.
Example:
$ python BaseTools/Scripts/PatchCheck.py 1a04951309
Checking git commit: 1a04951309
The 'Author' email address is not valid:
* The email address cannot contain a space: /o=Intel/ou=External \
(FYDIBOHF25SPDLT)/cn=Recipients/cn=fe425ca7e5f4401abed22b904fe5d964
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
We are checking different emails from the signature list. We are
going to check more. To be able to differency, add a description
field, so the error reported is clearer.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
To avoid patches committed with incorrect email address,
use the EmailAddressCheck class on the committer email too.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
As we are going to reuse this code out of the CommitMessageCheck
class, extract it in a new class: EmailAddressCheck.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=113
Strip the trailing characters before checking the subject line is
less than 72 characters.
Fixes: e61406708c
Cc: Liming Gao <liming.gao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
If git finds a '\r' character in the message, then it
converts the entire message content into Quoted-Printable
encoding. It appears that when groups.io converts the QP
encoding back to text format, the '\r' characters somehow
become '\n'. To workaround this, the SetupGit.py script
will now explicitly set the sendemail.transferEncoding git
config option to '8bit'
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
This issue happens under two conditions.
1. Unicode language environment in Windows
2. Python2 (Not reproducible with Python3)
Step to reproduce
C:\edk2>edksetup.bat forcerebuild
The edksetup.bat stuck at 'nmake cleanall'.
Signed-off-by: Aiden Park <aiden.park@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2311
In patch set 13c5e34a - 0c3e8e99, we implemented incremental build with
using compiler/pre-processor generate dependent header file function.
A issue is found for MSVC compiler, that the cl.exe /showIncludes
build option generate header file list to either stdout or stderr.
For .c file, the header file list is print out to stdout while for
.vfr, .aslc and .nasm file, the file list is print out to stderr.
The build tool use two threads to process the message from stdout and
stderr, but to generate correct *.deps file, build tool need to
combine the header file list from stderr and other messages from stdout
together with correct time sequence order.
So this patch is trying to combine the stdout and stderr together for
the process which is for calling make program.
The impact of this patch is that the output message of build with -q
will be changed. The compiler error message will not print out.
The build behavior of other log level setting will not be impacted.
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Steven Shi <steven.shi@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2423
That commit 13c5e34a1b introduces the first two UTF-8
characters (the quote ') in an otherwise all-ascii file.
In Conf\tools_def.template
There is tow lines of
Notes: Since this tool chain is obsolete, it doesn't enable
the compiler option for included header file list generation,
we replaces the two offending quotes by proper ascii quotes
The patch is going to fix this issue
Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2371
This patch is to fix a regression issue that build fails
if multiple build targets given.
Two changes cause this regression issue.
One is AutoGen object __hash__ function only
hash file path and arch, missing ToolChain and build target.
The other is changing the multiple-thread-genfds function as default
build behavior. To generate the genffs command to Makefile, there
is a global data set is used, GenFdsGlobalVariable, which cause build
tool use the data of first build-target build in
the second build-target build.
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Steven Shi <steven.shi@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Redesign the binary cache and not need to save the
cache intermediate result and state in memory as a
ModuleBuildCacheIR class instance. So remove the
CacheIR.py which define the ModuleBuildCacheIR class.
Signed-off-by: Steven Shi <steven.shi@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Redesign the binary cache and bases on the compiler to
output the dependency header files info for every module.
The binary cache will directly consume the dependency header
files info and doesn't parse the C source code by iteself.
Also redesign the dependency files list format for module
and try to share the common lib hash result as more as
possible in local process. Remove the unnecessary share data
access across multiprocessing.
Signed-off-by: Steven Shi <steven.shi@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Enhance the CacheCopyFile method arg names to be more
clear and readable
Signed-off-by: Steven Shi <steven.shi@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Binary cache use the OutputFile method to return the module
built output files needed to store in cache, but current
OutputFile implementation doesn't return complete output files.
Enhance the OutputFile method to return more complete output files.
Signed-off-by: Steven Shi <steven.shi@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2311
Include dependency file in Makefile to enhance
incremental build
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Steven Shi <steven.shi@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2311
Enable the dependent files generation function for compilers
and Trim tool.
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Steven Shi <steven.shi@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2311
Implement the function in Trim tool to get the included
file list for ASL and ASM file.
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Steven Shi <steven.shi@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2311
Add /showIncludes for msvc and -MMD -MF $@.deps
for GCC and CLANG
Remove /MP for msvc since /MP does not work with
/showIncludes
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Steven Shi <steven.shi@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2304
The following statement produces a SyntaxWarning with Python 3.8:
if str(FdRegion.RegionType) is 'FILE' and self.Platform.VpdToolGuid in \
str(FdRegion.RegionDataList):
BaseTools/Source/Python/AutoGen/WorkspaceAutoGen.py:168: SyntaxWarning: \
"is" with a literal. Did you mean "=="?
Change the 'is' operator by the conventional '==' comparator.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2400
In Dsc Parser, included dsc file is parsed always no matter
if its condition is False
gUefiOvmfPkgTokenSpaceGuid.test1|FALSE
!if gUefiOvmfPkgTokenSpaceGuid.test1 == FALSE
!include OvmfPkg/test1.dsc
!else
!include OvmfPkg/test2.dsc
!endif
The patch avoids processing redundant dsc files and improves
the way Tool handles them.
In the above case, since the conditional result is FALSE,
"test2.dsc" is not parsed.
Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2363
This patch is to fix a build tool regression issue which was introduced
by commit b8ac0b7f28.This issue caused map file lost the line of IMAGE=***.
For example,in Ovmf.map, there is no line of (IMAGE=<path to efi> ) under
each of modules item.
The path to the efi file generated by each module is written on this line
The purpose of this line is add the debug image full path.
there is no information about the module in the map file other than FVName,
it allows us to quickly know which module this part corresponds to.
In commit b8ac0b7f28,add a line ("self.BuildModules = []") in function,
but it's used to calculate the variable ModuleList in the following code.
Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Bob Feng
Liu, Zhiguang
Fan, ZhijuX
Pierre Gondois
Vitaly Cheptsov
Michael D Kinney
Sean Brogan
Steven
Liming Gao
Philippe Mathieu-Daude
Laszlo Ersek
Li, Aaron
Desimone, Nathaniel L
Park, Aiden