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.falc...@gmail.com> > Sent: Friday, December 15, 2023 9:04 AM > To: devel@edk2.groups.io; Chen, Christine <yuwei.c...@intel.com> > Cc: Gao, Liming <gaolim...@byosoft.com.cn>; Rebecca Cran > <rebe...@bsdio.com>; Zimmer, Vincent <vincent.zim...@intel.com>; Kinney, > Michael D <michael.d.kin...@intel.com>; Leif Lindholm > <quic_llind...@quicinc.com>; Andrew Fish <af...@apple.com>; Feng, Bob C > <bob.c.f...@intel.com>; Yang, Yuting2 <yuting2.y...@intel.com>; Hartung, > Stephen <stephen.hart...@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.c...@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 (#112605): https://edk2.groups.io/g/devel/message/112605 Mute This Topic: https://groups.io/mt/102486097/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
