Re: [PATCH 0/3] Fix xmm_t to rte_xmm_t scalar conversion

[Thomas Monjalon <thomas@monjalon.net>]

21/06/2022 13:05, Stanisław Kardach:
> On Tue, Jun 21, 2022 at 12:22 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> >
> > 21/06/2022 11:49, Bruce Richardson:
> > > On Tue, Jun 21, 2022 at 11:42:55AM +0200, Stanisław Kardach wrote:
> > > > On Tue, Jun 21, 2022 at 11:39 AM Bruce Richardson
> > > > <bruce.richardson@intel.com> wrote:
> > > > > <snip>
> > > > > Generally the "cpp" binary is not the c-plus-plus one, but the C
> > > > > preprocessor one. Perhaps the original files are incorrect here, and should
> > > > > all refer to g++.
> > > > >
> > > > > /Bruce
> > > > >
> > > > That does make sense. I'll submit a separate patchset fixing all
> > > > occurrences (of which there are many).
> > > >
> > >
> > > As a more general note for future consideration, I notice that in meson
> > > 0.56 the cross-file support has been enhanced with the ability to use
> > > constants and therefore separate out prefixes.[1]
> > >
> > > When we get to the point where we feel we can mandate meson 0.56 upwards
> > > for cross compilation, we should look to leverage this. It should even
> > > allow other scripts such as test-meson-builds to auto-generate the constant
> > > paths to the binaries on the fly, effectively allowing the use of
> > > environment variables for these - something previously requested by Thomas.
> >
> > That would be great.
> > Cross compilation prefix is such a basic thing, we should handle it properly.
> Please correct me if I'm wrong but it seems that meson's approach to
> cross-compiling is to package all settings into cross-files. Probably
> under assumption that a repeatable compilation is more important than
> flexibility and that there are compiler-specific knobs that need/can
> to be tuned. Therefore reading CROSS_COMPILE/prefix from environment
> is intentionally made hard.

If it is made intentionally hard, it is just a wrong design.
A toolchain prefix is just a name.
We can have 2 toolchains compiled with the same name and different behaviours.
And we can have 2 similar toolchains with a different name.

> So should the direction be environment or rather separating
> cross-files into arch-part and toolchain-parts and letting user create
> his own toolchain part while maintaining a matrix of supported
> combinations for CI? I'm not advocating either, just want to wrap my
> head around it.

We should be able to use a toolchain compiled anywhere
without modifying the cross files, just because a "-gnu-" is missing
or any other irrelevant detail.