Re: [edk2-devel] [edk2-stable202311][PATCH] BaseTools: Python VfrCompiler implementation

["Yuwei Chen" <yuwei.chen@intel.com>]

Hi Liming,

Have you tried with the new python tool? Any comments or concerns?

Thanks,
Christine

> -----Original Message-----
> From: Kinney, Michael D <michael.d.kinney@intel.com>
> Sent: Saturday, December 16, 2023 1:31 AM
> To: Pedro Falcato <pedro.falcato@gmail.com>; devel@edk2.groups.io; Chen,
> Christine <yuwei.chen@intel.com>
> Cc: Gao, Liming <gaoliming@byosoft.com.cn>; Rebecca Cran
> <rebecca@bsdio.com>; Zimmer, Vincent <vincent.zimmer@intel.com>; Leif
> Lindholm <quic_llindhol@quicinc.com>; Andrew Fish <afish@apple.com>;
> Feng, Bob C <bob.c.feng@intel.com>; Yang, Yuting2
> <yuting2.yang@intel.com>; Hartung, Stephen <stephen.hartung@intel.com>;
> Kinney, Michael D <michael.d.kinney@intel.com>
> Subject: RE: [edk2-devel] [edk2-stable202311][PATCH] BaseTools: Python
> VfrCompiler implementation
> 
> There are several advantages for this direction:
> 
> 
> * Current VFR compiler in C has dependencies on very old libs that
>   have not been updated.
> 
> * The movement to python will remove the pre-build step that requires
>   some of the build tools to be built using host C compiler before
>   running edk2 build command.
> 
> * The other element is moving all the python code into edk2-basetools
>   repo with a published pip package.  This enables the use of
>   pip-requirements.txt to provide developers all the content needed
>   to build.
> 
> I agree that we should not have both VFR compilers.  We need to make sure
> the new one in Python is 100% compatible with the C version and make the
> decision to simultaneously add Python one and delete the C one and commit
> to the Python one.  I provided this feedback to the VFR developers in the
> TianoCore Tools/CI meeting earlier this year.
> 
> The perf question is very good. It would be good for the VFR developers to
> provide some perf comparisons.  I do not expect any significant different that
> would impact overall platform build times.
> 
> Mike
> 
> > -----Original Message-----
> > From: Pedro Falcato <pedro.falcato@gmail.com>
> > Sent: Friday, December 15, 2023 9:04 AM
> > To: devel@edk2.groups.io; Chen, Christine <yuwei.chen@intel.com>
> > Cc: Gao, Liming <gaoliming@byosoft.com.cn>; Rebecca Cran
> > <rebecca@bsdio.com>; Zimmer, Vincent <vincent.zimmer@intel.com>;
> > Kinney, Michael D <michael.d.kinney@intel.com>; Leif Lindholm
> > <quic_llindhol@quicinc.com>; Andrew Fish <afish@apple.com>; Feng, Bob
> > C <bob.c.feng@intel.com>; Yang, Yuting2 <yuting2.yang@intel.com>;
> > Hartung, Stephen <stephen.hartung@intel.com>
> > Subject: Re: [edk2-devel] [edk2-stable202311][PATCH] BaseTools: Python
> > VfrCompiler implementation
> >
> > On Thu, Dec 7, 2023 at 9:08 AM Yuwei Chen <yuwei.chen@intel.com>
> wrote:
> > >
> > > Hi Liming,
> > >
> > >
> > >
> > > Is this feature been tested and reviewed these two weeks? 😊
> >
> > Two questions:
> >
> > 1) What testing strategy do you have to test for regressions in such a
> > huge rewrite?
> > 2) What's the point in shipping this to upstream if you're not aiming
> > for the replacement of the original VfrCompiler?
> > 3) What's the value of rewriting this in Python? If the existing
> > VfrCompiler is already working fine (AFAIK?), a python version will
> > likely just be slower (unless the original C version is super badly
> > written).
> > I *seriously* struggle to understand what this Python movement is
> > supposed to do, except gratuitously rewrite large bits of BaseTools
> > for a net loss (performance)
> >
> > --
> > Pedro


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113430): https://edk2.groups.io/g/devel/message/113430
Mute This Topic: https://groups.io/mt/102486097/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-