> -----Original Message-----
> From: Thomas Monjalon <tho...@monjalon.net>
> Sent: Wednesday, February 24, 2021 1:10 PM
> To: Juraj Linkeš <juraj.lin...@pantheon.tech>
> Cc: oulijun <ouli...@huawei.com>; ferruh.yi...@intel.com; dev@dpdk.org;
> linux...@openeuler.org
> Subject: Re: [dpdk-dev] [PATCH 1/2] config/arm: fix Hisilicon kunpeng920 SoC
> build
>
> 24/02/2021 12:55, Juraj Linkeš:
> > From: dev <dev-boun...@dpdk.org> On Behalf Of Thomas Monjalon
> > > 24/02/2021 02:34, oulijun:
> > > >
> > > > 在 2021/2/10 17:41, Thomas Monjalon 写道:
> > > > > 03/02/2021 13:46, Lijun Ou:
> > > > >> From: Chengchang Tang <tangchengch...@huawei.com>
> > > > >>
> > > > >> Because of the '9ca2f16' have merged, the current hns3 pmd
> > > > >> driver can not be directly complied on the kunpeng920 server board.
> > > > >> Therefore, we need to fix the meson build.
> > > > >> Besides, add kunpeng 920 SoC meson cross compile target.
> > > > >>
> > > > >> Fixes: 9ca2f16faa7f ("config/arm: isolate generic build")
> > > > >
> > > > > Why do you think this patch is fixing the one above?
> > > > > It looks just a new config, not a fix. Am I missing something?
> > > > >
> > > > I'm sorry to see you so late. In the meantime, we are celebrating
> > > > the Spring Festival. This patch fixes the problem. If the patch is
> > > > not added, the latest version cannot be directly compiled on the
> > > > Kunpeng
> > > > 930 server board.In addition, the cross compilation configuration file
> > > > is
> added.
> > >
> > > Please can you explain what was removed which breaks your compilation?
> > >
> >
> > I can explain what's changed and why we changed it.
> >
> > The previous behavior was that when an uknown implementer was found
> (when we're building on an uknown build machine) we fell back to a generic
> build.
> > The current behavior is we raise an error when building on an unknown build
> machine and inform the user about the generic build (there's an error in the
> message, it should be -Dmachine=default instead of -Dmachine=generic). Lijun
> came across this scenario, so he wants to add an implementer, but it is not a
> fix,
> rather an addition that we wanted to encourage when we changed the
> behavior. The change in behavior also has an additional benefit in that it
> notifies
> the user that meson is not doing a tailored build for the build machine and
> the
> only permissible build is the generic one.
>
> There were already many fixes for that rework.
> Please check if there are other missing updates.
>
This is actually the first mistake that my testing missed. I tested that the
message is properly emitted, but I didn't test the message after we extracted
the default->generic rename patch. As a side note, we could address this issue
with
http://patches.dpdk.org/project/dpdk/patch/1613657555-17683-1-git-send-email-juraj.lin...@pantheon.tech/
- then we can leave the message in place as is (with -Dmachine=generic).
I went through all of the patches again but I didn't find anything that needs
addressing.
As far as I'm aware, there were two other fixes for the series. One was a
failure of communication (the native margs fix - I implemented what we thought
we agreed on) and the other is not really a fix, just the addition of one
implementer configuration (I removed the implementer because we didn't have its
configuration). The clang cross-compile fixes are related, but those are the
problem with that series, not the rework series.
>
>
