> -----Original Message-----
> From: Thomas Monjalon <tho...@monjalon.net>
> Sent: Tuesday, April 20, 2021 10:36 AM
> To: Juraj Linkeš <juraj.lin...@pantheon.tech>
> Cc: david.march...@redhat.com; bruce.richard...@intel.com;
> honnappa.nagaraha...@arm.com; ruifeng.w...@arm.com; dev@dpdk.org
> Subject: Re: [PATCH v5] build: use platform option for generic and native
>
> 20/04/2021 10:16, Juraj Linkeš:
> > > option('platform', type: 'string', value: '',
> > > - description: 'use configuration for a particular platform (such as a
> > > SoC).')
> > > +option('platform', type: 'string', value: 'generic',
> > > + description: 'Platform to build, either "native", "generic" or an
> > > +Arm SoC. Please refer to the Linux build guide for more
> > > +information.')
> >
> > The other thing we need to discuss is the fact that we're changing the
> > behavior
> in this patch from machine=native to platform=generic (and the implied
> cpu_instruction_set=genetic which equals to machine=generic). We need more
> feedback on this - Thomas, David? Should we include more people? The reason
> for this change is we want the build without any meson options (specified on
> cmdline) to be usable on as many different machines of the same architecture
> (this is my understanding form the discussion with Bruce), which is the
> generic
> platform. We could preserve the current behavior by setting the default to
> native, so we just need more discussion.
>
> I don't understand why you need to change the behaviour.
Well, we don't *need* to change the behavior - I don't mind it either way.
We've come to this point after discussing the change with Bruce. I believe
Bruce mentioned the intention of the build without any meson cmdline options
was to produce a build usable on most machines that match the build
architecture and the generic build fits better (native build being more
tailored to the build machine as opposed to the generic build).
I don't want to speak for Bruce though, so it'd be the best if he gave his
thoughts on the matter.
> If we change the behaviour, it must be done carefully after a deprecation
> notice
> and an agreement of the Technical Board.
>
>
Ok, one thing we could do is preserve the behavior in this patch and go through
this process with a separate change.
