From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [edk2-devel] [PATCH] BaseTools/Python: Add missing FatalError handling To: Bob Feng ,devel@edk2.groups.io From: "Irene Park" X-Originating-Location: Raleigh, North Carolina, US (12.22.141.131) X-Originating-Platform: Windows Chrome 83 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Fri, 29 May 2020 00:27:21 -0700 References: In-Reply-To: Message-ID: <10681.1590737241856320947@groups.io> Content-Type: multipart/alternative; boundary="HtuiepsAQ9wlKpJTyCk4" --HtuiepsAQ9wlKpJTyCk4 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Bob, Thanks for the review. Here is the original description of the issue. There has been a build failure from SCT, related to https://edk2.groups.io= /g/devel/message/60407?p=3D,,,20,0,0,0::relevance,,gEfiFormBrowserExProtoco= lGuid,20,2,0,74529350. ( https://edk2.groups.io/g/devel/message/60407?p=3D,= ,,20,0,0,0::relevance,,gEfiFormBrowserExProtocolGuid,20,2,0,74529350 ) The build log printed the error code obviously but returned with sys.exit(= 0). Unfortunately this behavior confused the build system and made me notice t= he failure so late. If there is a concern of the conflict among multiple autogenworkers, I won= der how you think this way. 1. No change in BaseTools/Source/Python/AutoGen/AutoGenWorker.py 2. BaseTools/Source/Python/build/build.py --- a/BaseTools/Source/Python/build/build.py +++ b/BaseTools/Source/Python/build/build.py @@ -880,7 +880,10 @@ class Build(): self.AutoGenMgr.join() rt =3D self.AutoGenMgr.Status -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return rt, 0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 err =3D 0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if not rt: +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 err =3D UNKNOWN_E= RROR << Use a fixed error type of FatalError instead of getting the exact e= rror type from the autogenworkers. +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return rt, err except FatalError as e: return False, e.args[0] except: In this way, no change in the multi-thread operation and build.py is able = to exit with a standard default error. It's not needed to catch the exact e= rror type. Please share your opinion. Thanks, Irene --HtuiepsAQ9wlKpJTyCk4 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Bob,

Thanks for the review.
Here is the original description of the iss= ue.
There has been a build failure from SCT, related to https://edk2.groups.io/g/= devel/message/60407?p=3D,,,20,0,0,0::relevance,,gEfiFormBrowserExProtocolGu= id,20,2,0,74529350.
The build log printed the error code obviously= but returned with sys.exit(0).
Unfortunately this behavior confused t= he build system and made me notice the failure so late.
If there is a = concern of the conflict among multiple autogenworkers, I wonder how you thi= nk this way.

1. No change in BaseTools/Source/Python/AutoGen/Aut= oGenWorker.py
2. BaseTools/Source/Python/build/build.py

--- a/BaseTools/Source/Python/build/build.py

+++ b/BaseTools/Source/Python/build/build.py

@@ -880,7 +880,10 @@ class Build():

 

             self.AutoGenMgr.join()<= /p>

             rt =3D self.AutoGenMgr.= Status

-            return rt, 0

+            err =3D 0

+            if not rt:

+                err =3D UNKNOW= N_ERROR << Use a fixed error type of FatalError instead of getting th= e exact error type from the autogenworkers.

+            return rt, err

         except FatalError as e:

             return False, e.args[0]=

         except:


In this way, no change in the multi-thread operation and build.py= is able to exit with a standard default error. It's not needed to catch th= e exact error type.
Please share your opinion.

Thanks,
Irene


 

--HtuiepsAQ9wlKpJTyCk4--