On 04/14/16 13:10, Laszlo Ersek wrote:
> On 04/13/16 11:47, Yonghong Zhu wrote:
>> when enable Multiple workspace and there have other option(eg: -I) before
>> $(WORKSPACE), handleWsMacro cannot return correct which cause the
>> ArmVirtPkg build failure.
>> example:
>> [BuildOptions]
>>   *_*_AARCH64_PLATFORM_FLAGS == -I$(WORKSPACE)/ArmVirtPkg/Include
>>
>> Cc: Liming Gao <liming....@intel.com>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Yonghong Zhu <yonghong....@intel.com>
>> ---
>>  BaseTools/Source/Python/Common/MultipleWorkspace.py | 19 ++++++++++++-------
>>  1 file changed, 12 insertions(+), 7 deletions(-)
>>
>> diff --git a/BaseTools/Source/Python/Common/MultipleWorkspace.py 
>> b/BaseTools/Source/Python/Common/MultipleWorkspace.py
>> index feb1f8d..4e4c37a 100644
>> --- a/BaseTools/Source/Python/Common/MultipleWorkspace.py
>> +++ b/BaseTools/Source/Python/Common/MultipleWorkspace.py
>> @@ -2,11 +2,11 @@
>>  # manage multiple workspace file.
>>  #
>>  # This file is required to make Python interpreter treat the directory
>>  # as containing package.
>>  #
>> -# Copyright (c) 2015, Intel Corporation. All rights reserved.<BR>
>> +# Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.<BR>
>>  # This program and the accompanying materials
>>  # are licensed and made available under the terms and conditions of the BSD 
>> License
>>  # which accompanies this distribution.  The full text of the license may be 
>> found at
>>  # http://opensource.org/licenses/bsd-license.php
>>  #
>> @@ -126,16 +126,21 @@ class MultipleWorkspace(object):
>>      #   @retval PathStr   Path string include the $(WORKSPACE)
>>      #
>>      @classmethod
>>      def handleWsMacro(cls, PathStr):
>>          if TAB_WORKSPACE in PathStr:
>> -            Path = PathStr.replace(TAB_WORKSPACE, cls.WORKSPACE).strip()
>> -            if not os.path.exists(Path):
>> -                for Pkg in cls.PACKAGES_PATH:
>> -                    Path = PathStr.replace(TAB_WORKSPACE, Pkg).strip()
>> -                    if os.path.exists(Path):
>> -                        return Path
>> +            PathList = PathStr.split()
>> +            if PathList:
>> +                for i, str in enumerate(PathList):
>> +                    if str.find(TAB_WORKSPACE) != -1:
>> +                        MacroStartPos = str.find(TAB_WORKSPACE)
>> +                        MacroEndPos = str.find(')', MacroStartPos)
>> +                        Substr = str[MacroEndPos+1:]
>> +                        if Substr.startswith('/') or 
>> Substr.startswith('\\'):
>> +                            Substr = Substr[1:]
>> +                        PathList[i] = str[0:MacroStartPos] + 
>> os.path.normpath(cls.join(cls.WORKSPACE, Substr))
>> +            PathStr = ' '.join(PathList)
>>          return PathStr
>>      
>>      ## getPkgPath()
>>      #
>>      #   get all package pathes.
>>
> 
> Gerd's CI reported a build failure for OVMF. I've identified this patch 
> (commit 2b1c08acfceb) as the culprit. When I revert this patch, the build 
> succeeds again.
> 
> The commands leading up to the error, and the error, are:
> 
> "gcc" -E -x assembler-with-cpp -include 
> Build/OvmfIa32/DEBUG_GCC49/IA32/OvmfPkg/ResetVector/ResetVector/DEBUG/AutoGen.h
>  -IOvmfPkg/ResetVector 
> -IBuild/OvmfIa32/DEBUG_GCC49/IA32/OvmfPkg/ResetVector/ResetVector/DEBUG 
> -IMdePkg -IMdePkg/Include -IMdePkg/Include/Ia32 -IUefiCpuPkg 
> -IUefiCpuPkg/Include OvmfPkg/ResetVector/ResetVector.nasmb > 
> Build/OvmfIa32/DEBUG_GCC49/IA32/OvmfPkg/ResetVector/ResetVector/OUTPUT/ResetVector.i
> 
> Trim --source-code --convert-hex -o 
> Build/OvmfIa32/DEBUG_GCC49/IA32/OvmfPkg/ResetVector/ResetVector/OUTPUT/ResetVector.iii
>  
> Build/OvmfIa32/DEBUG_GCC49/IA32/OvmfPkg/ResetVector/ResetVector/OUTPUT/ResetVector.i
> 
> "nasm" -IOvmfPkg/ResetVector/ -l 
> Build/OvmfIa32/DEBUG_GCC49/IA32/OvmfPkg/ResetVector/ResetVector/OUTPUT/ResetVector.lst
>  -f bin -IUefiCpuPkg/ResetVector/Vtf0 -o 
> Build/OvmfIa32/DEBUG_GCC49/IA32/OvmfPkg/ResetVector/ResetVector/OUTPUT/ResetVector.bin
>  
> Build/OvmfIa32/DEBUG_GCC49/IA32/OvmfPkg/ResetVector/ResetVector/OUTPUT/ResetVector.iii
> 
> Build/OvmfIa32/DEBUG_GCC49/IA32/OvmfPkg/ResetVector/ResetVector/OUTPUT/ResetVector.iii:40:
>  fatal: unable to open include file `CommonMacros.inc'

The INF file "OvmfPkg/ResetVector/ResetVector.inf" has:

[BuildOptions]
   *_*_IA32_NASMB_FLAGS = -I$(WORKSPACE)/UefiCpuPkg/ResetVector/Vtf0/
   *_*_X64_NASMB_FLAGS = -I$(WORKSPACE)/UefiCpuPkg/ResetVector/Vtf0/

Looking at the "-I" options on the "nasm" command line above, we have:

  -IOvmfPkg/ResetVector/
  -IUefiCpuPkg/ResetVector/Vtf0

... Aaargh, I found it! The patch calls the os.path.normpath() function,
which -- as part of the normalization -- removes the trailing slash
character. Compare:

  -IUefiCpuPkg/ResetVector/Vtf0/

versus

  -IUefiCpuPkg/ResetVector/Vtf0

With the first form, NASM finds the "CommonMacros.inc" include file.
With the second form, NASM doesn't find the include file.

>From the NASM manual page:

       -I|-i directory
           Adds a directory to the search path for include files. The
           directory specification must include the trailing slash, as
           it will be directly prepended to the name of the include
           file.

Therefore it is not a NASM bug (it is a documented requirement); it is a
bug in BaseTools.

What is the reason for calling os.path.normpath()? The pre-patch code
didn't include it at all.

Thanks
Laszlo
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Reply via email to