Re: [dpdk-dev] Meson Minimum Version

Re: [dpdk-dev] Meson Minimum Version

[John Alexander]

Hi,

Regarding the subproject local patch support, yes, it's only supported since Meson 0.55: https://mesonbuild.com/Wrap-dependency-system-manual.html  We pip installed 0.55 Meson.

I have a number of subsequent patches that depend on this particular pthreads library to advance the Windows DPDK support.  Locally, we have testpmd (minus mmap'd external memory currently) running against the Intel i40e PMD (XL710 4x10Gbps SPF+ NIC) on Windows on our local DPDK fork (based off 20.08-rc2 using Microsoft's latest NetUIO driver).  We have 47 of the 51 RTE libraries building and have had l2fwd, l3fwd, ipv4_multicast and almost all of the regression tests compiling+linking too.    I'd like to push as much of the Windows EAL work we've done upstream if I can (after a bit of tidying up :).
 
I've also coded up a meson build patch for the Jansson JSON parser used by the RTE metrics library (the config.h generation was quite fiddly!)  That's ready to go.  We get nice meson syntax as follows to specify a fallback if the library isn't installed locally:
	jansson = dependency('jansson', required: false, fallback : ['jansson', 'jansson_static_dep'])
I believe the meson command line enables disabling fallbacks if people would prefer not to use them (--wrap-mode=nofallback).

Kind regards,
John.

----------------------------------------------------------------------


Date: Thu, 24 Sep 2020 15:38:30 +0100
From: Bruce Richardson <bruce.richardson@intel.com>
To: John Alexander <John.Alexander@datapath.co.uk>
Cc: "dev@dpdk.org" <dev@dpdk.org>, techboard@dpdk.org
Subject: Re: [dpdk-dev] Meson Minimum Version
Message-ID: <20200924143830.GD382@bricha3-MOBL.ger.corp.intel.com>
Content-Type: text/plain; charset=us-ascii

On Thu, Sep 24, 2020 at 02:22:03PM +0000, John Alexander wrote:
> Hi,
>
> I've submitted a patch that uses new features of Meson, specifically the directory patch aspect of the subproject feature.  This requires a minimum Meson version of 0.55.0.  How do we go about getting the community to accept a more recent version of Meson and getting the Travis server upgraded too so the CI builds succeed?
>
> Patch link for reference: http://patches.dpdk.org/patch/78675/
>
Hi John,

from what I understand the specific dependency on 0.55 is the support for local patchfiles for the wrapped software, and that previous versions only supported using patches pulled remotely - is that correct?

While I'm in favour of incrementing the minimum meson version in general, since 0.55 is the very latest version I am worried about any impacts that might have, since it will basically mean that everyone building DPDK has to pull meson from pip rather than being able to use a distro-supplied version. Updating to something a little less recent would be more my preference.

Then again, using the wrap system to pull in dependencies seems something really good to have, so maybe the initial pain of requiring a recent meson is worth it!

Thoughts from others?

Regards,
/Bruce

Re: [dpdk-dev] Meson Minimum Version

[Bruce Richardson]

On Thu, Sep 24, 2020 at 03:32:41PM +0000, John Alexander wrote:
>    Hi,
>    Regarding the subproject local patch support, yes, it's only supported
>    since Meson 0.55:
>    https://mesonbuild.com/Wrap-dependency-system-manual.html We pip
>    installed 0.55 Meson.
>    I have a number of subsequent patches that depend on this particular
>    pthreads library to advance the Windows DPDK support. Locally, we have
>    testpmd (minus mmap'd external memory currently) running against the
>    Intel i40e PMD (XL710 4x10Gbps SPF+ NIC) on Windows on our local DPDK
>    fork (based off 20.08-rc2 using Microsoft's latest NetUIO driver). We
>    have 47 of the 51 RTE libraries building and have had l2fwd, l3fwd,
>    ipv4_multicast and almost all of the regression tests compiling+linking
>    too. I'd like to push as much of the Windows EAL work we've done
>    upstream if I can (after a bit of tidying up :).
>    I've also coded up a meson build patch for the Jansson JSON parser used
>    by the RTE metrics library (the config.h generation was quite fiddly!)
>    That's ready to go. We get nice meson syntax as follows to specify a
>    fallback if the library isn't installed locally:
>    jansson = dependency('jansson', required: false, fallback : ['jansson',
>    'jansson_static_dep'])
>    I believe the meson command line enables disabling fallbacks if people
>    would prefer not to use them (--wrap-mode=nofallback).
>    Kind regards,
>    John.

Hi again, John,

thanks for the full reply - the work you have sounds really good, and the
possibilities using the wrap support are definitely of interest. [Though
since jansson is only used for the legacy parts of the telemetry library
I'm not sure we want to wrap it just for that - the later telemetry work
from this year doesn't depend on jansson. Then again, the vm_power_manager
example also uses it too...]. It's probably something that would be
especially useful for software dependencies that aren't normally packaged.

I've added techboard on CC to previous reply, so hopefully we'll get some
thoughts from others.

Regards,
/Bruce

PS: please don't top-post in replying and keep plain text email if
possible. Thanks.

>    ----------------------------------------------------------------------
>    Date: Thu, 24 Sep 2020 15:38:30 +0100
>    From: Bruce Richardson <bruce.richardson@intel.com>
>    To: John Alexander <John.Alexander@datapath.co.uk>
>    Cc: "dev@dpdk.org" <dev@dpdk.org>, techboard@dpdk.org
>    Subject: Re: [dpdk-dev] Meson Minimum Version
>    Message-ID: <20200924143830.GD382@bricha3-MOBL.ger.corp.intel.com>
>    Content-Type: text/plain; charset=us-ascii
>    On Thu, Sep 24, 2020 at 02:22:03PM +0000, John Alexander wrote:
>    > Hi,
>    >
>    > I've submitted a patch that uses new features of Meson, specifically
>    the directory patch aspect of the subproject feature. This requires a
>    minimum Meson version of 0.55.0. How do we go about getting the
>    community to accept a more recent version of Meson and getting the
>    Travis server upgraded too so the CI builds succeed?
>    >
>    > Patch link for reference: http://patches.dpdk.org/patch/78675/
>    >
>    Hi John,
>    from what I understand the specific dependency on 0.55 is the support
>    for local patchfiles for the wrapped software, and that previous
>    versions only supported using patches pulled remotely - is that
>    correct?
>    While I'm in favour of incrementing the minimum meson version in
>    general, since 0.55 is the very latest version I am worried about any
>    impacts that might have, since it will basically mean that everyone
>    building DPDK has to pull meson from pip rather than being able to use
>    a distro-supplied version. Updating to something a little less recent
>    would be more my preference.
>    Then again, using the wrap system to pull in dependencies seems
>    something really good to have, so maybe the initial pain of requiring a
>    recent meson is worth it!
>    Thoughts from others?
>    Regards,
>    /Bruce
> 
>    John Alexander​
>    Senior Software Engineer
>    Bemrose House, Bemrose Park, Wayzgoose Drive ,  Derby ,  DE21 6XQ
>    [1]+44 (0)1332 294 441  |  [2]www.datapath.co.uk
>    [3]LinkedIn
>    [4]Twitter
>    [5]YouTube
>    [6]Vote for Datapath
>    Datapath Ltd.  Registered Number: 1609392.  Registered in England at Be
>    mrose House, Bemrose Park, Wayzgoose Drive, Derby. DE21 6XQ.
> 
> References
> 
>    Visible links
>    1. tel:+44%20(0)1332%20294%20441
>    2. http://www.datapath.co.uk/
>    3. https://www.linkedin.com/company/datapath-ltd
>    4. https://www.twitter.com/datapathltd
>    5. https://www.youtube.com/datapathderby
>    6. https://nbmedia.wufoo.com/forms/z17utbme1olkvqz/
> 
>    Hidden links:
>    7. http://www.datapath.co.uk/

Re: [dpdk-dev] Meson Minimum Version

[Morten Brørup]

> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson
> Sent: Thursday, September 24, 2020 5:43 PM
> 
> On Thu, Sep 24, 2020 at 03:32:41PM +0000, John Alexander wrote:
> >    Hi,
> >    Regarding the subproject local patch support, yes, it's only
> supported
> >    since Meson 0.55:
> >    https://mesonbuild.com/Wrap-dependency-system-manual.html We pip
> >    installed 0.55 Meson.
> >    I have a number of subsequent patches that depend on this
> particular
> >    pthreads library to advance the Windows DPDK support. Locally, we
> have
> >    testpmd (minus mmap'd external memory currently) running against
> the
> >    Intel i40e PMD (XL710 4x10Gbps SPF+ NIC) on Windows on our local
> DPDK
> >    fork (based off 20.08-rc2 using Microsoft's latest NetUIO driver).
> We
> >    have 47 of the 51 RTE libraries building and have had l2fwd,
> l3fwd,
> >    ipv4_multicast and almost all of the regression tests
> compiling+linking
> >    too. I'd like to push as much of the Windows EAL work we've done
> >    upstream if I can (after a bit of tidying up :).
> >    I've also coded up a meson build patch for the Jansson JSON parser
> used
> >    by the RTE metrics library (the config.h generation was quite
> fiddly!)
> >    That's ready to go. We get nice meson syntax as follows to specify
> a
> >    fallback if the library isn't installed locally:
> >    jansson = dependency('jansson', required: false, fallback :
> ['jansson',
> >    'jansson_static_dep'])
> >    I believe the meson command line enables disabling fallbacks if
> people
> >    would prefer not to use them (--wrap-mode=nofallback).
> >    Kind regards,
> >    John.
> 
> Hi again, John,
> 
> thanks for the full reply - the work you have sounds really good, and
> the
> possibilities using the wrap support are definitely of interest.
> [Though
> since jansson is only used for the legacy parts of the telemetry
> library
> I'm not sure we want to wrap it just for that - the later telemetry
> work
> from this year doesn't depend on jansson. Then again, the
> vm_power_manager
> example also uses it too...]. It's probably something that would be
> especially useful for software dependencies that aren't normally
> packaged.
> 
> I've added techboard on CC to previous reply, so hopefully we'll get
> some
> thoughts from others.
> 

A buggy C compiler might generate buggy code, and the compiler induced bugs may not be caught during development (but hopefully during testing). I have seen this happen, and I still consider it a realistic scenario. This is the strongest argument for using a trusted version of the C compiler, which is supported by the popular GNU/Linux distributors (Red Hat etc.), or sufficiently vetted to be included in the Crosstool-NG project, or similar.

Meson is a relatively simple tool, so I personally wouldn't mind overwriting the distro-supported version on our build systems with a new version. (I haven't worked much with Meson, but assume that the new version of Meson is backwards compatible with its earlier versions.)

In short, my primary concern is: What could realistically go wrong if the required version of Meson is buggy?

Bruce, you have worked for quite a while with Meson/Ninja by now, so perhaps you can assess this risk based on your experience.


> Regards,
> /Bruce
> 
> PS: please don't top-post in replying and keep plain text email if
> possible. Thanks.
> 
> >    ------------------------------------------------------------------
> ----
> >    Date: Thu, 24 Sep 2020 15:38:30 +0100
> >    From: Bruce Richardson <bruce.richardson@intel.com>
> >    To: John Alexander <John.Alexander@datapath.co.uk>
> >    Cc: "dev@dpdk.org" <dev@dpdk.org>, techboard@dpdk.org
> >    Subject: Re: [dpdk-dev] Meson Minimum Version
> >    Message-ID: <20200924143830.GD382@bricha3-MOBL.ger.corp.intel.com>
> >    Content-Type: text/plain; charset=us-ascii
> >    On Thu, Sep 24, 2020 at 02:22:03PM +0000, John Alexander wrote:
> >    > Hi,
> >    >
> >    > I've submitted a patch that uses new features of Meson,
> specifically
> >    the directory patch aspect of the subproject feature. This
> requires a
> >    minimum Meson version of 0.55.0. How do we go about getting the
> >    community to accept a more recent version of Meson and getting the
> >    Travis server upgraded too so the CI builds succeed?
> >    >
> >    > Patch link for reference: http://patches.dpdk.org/patch/78675/
> >    >
> >    Hi John,
> >    from what I understand the specific dependency on 0.55 is the
> support
> >    for local patchfiles for the wrapped software, and that previous
> >    versions only supported using patches pulled remotely - is that
> >    correct?
> >    While I'm in favour of incrementing the minimum meson version in
> >    general, since 0.55 is the very latest version I am worried about
> any
> >    impacts that might have, since it will basically mean that
> everyone
> >    building DPDK has to pull meson from pip rather than being able to
> use
> >    a distro-supplied version. Updating to something a little less
> recent
> >    would be more my preference.
> >    Then again, using the wrap system to pull in dependencies seems
> >    something really good to have, so maybe the initial pain of
> requiring a
> >    recent meson is worth it!
> >    Thoughts from others?
> >    Regards,
> >    /Bruce
> >
> >    John Alexander​
> >    Senior Software Engineer
> >    Bemrose House, Bemrose Park, Wayzgoose Drive ,  Derby ,  DE21 6XQ
> >    [1]+44 (0)1332 294 441  |  [2]www.datapath.co.uk
> >    [3]LinkedIn
> >    [4]Twitter
> >    [5]YouTube
> >    [6]Vote for Datapath
> >    Datapath Ltd.  Registered Number: 1609392.  Registered in England
> at Be
> >    mrose House, Bemrose Park, Wayzgoose Drive, Derby. DE21 6XQ.
> >
> > References
> >
> >    Visible links
> >    1. tel:+44%20(0)1332%20294%20441
> >    2. http://www.datapath.co.uk/
> >    3. https://www.linkedin.com/company/datapath-ltd
> >    4. https://www.twitter.com/datapathltd
> >    5. https://www.youtube.com/datapathderby
> >    6. https://nbmedia.wufoo.com/forms/z17utbme1olkvqz/
> >
> >    Hidden links:
> >    7. http://www.datapath.co.uk/
> 

Re: [dpdk-dev] Meson Minimum Version

[Bruce Richardson]

On Fri, Sep 25, 2020 at 09:31:53AM +0200, Morten Brørup wrote:
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson
> > Sent: Thursday, September 24, 2020 5:43 PM
> > 
> > On Thu, Sep 24, 2020 at 03:32:41PM +0000, John Alexander wrote:
> > >    Hi,
> > >    Regarding the subproject local patch support, yes, it's only
> > supported
> > >    since Meson 0.55:
> > >    https://mesonbuild.com/Wrap-dependency-system-manual.html We pip
> > >    installed 0.55 Meson.
> > >    I have a number of subsequent patches that depend on this
> > particular
> > >    pthreads library to advance the Windows DPDK support. Locally, we
> > have
> > >    testpmd (minus mmap'd external memory currently) running against
> > the
> > >    Intel i40e PMD (XL710 4x10Gbps SPF+ NIC) on Windows on our local
> > DPDK
> > >    fork (based off 20.08-rc2 using Microsoft's latest NetUIO driver).
> > We
> > >    have 47 of the 51 RTE libraries building and have had l2fwd,
> > l3fwd,
> > >    ipv4_multicast and almost all of the regression tests
> > compiling+linking
> > >    too. I'd like to push as much of the Windows EAL work we've done
> > >    upstream if I can (after a bit of tidying up :).
> > >    I've also coded up a meson build patch for the Jansson JSON parser
> > used
> > >    by the RTE metrics library (the config.h generation was quite
> > fiddly!)
> > >    That's ready to go. We get nice meson syntax as follows to specify
> > a
> > >    fallback if the library isn't installed locally:
> > >    jansson = dependency('jansson', required: false, fallback :
> > ['jansson',
> > >    'jansson_static_dep'])
> > >    I believe the meson command line enables disabling fallbacks if
> > people
> > >    would prefer not to use them (--wrap-mode=nofallback).
> > >    Kind regards,
> > >    John.
> > 
> > Hi again, John,
> > 
> > thanks for the full reply - the work you have sounds really good, and
> > the
> > possibilities using the wrap support are definitely of interest.
> > [Though
> > since jansson is only used for the legacy parts of the telemetry
> > library
> > I'm not sure we want to wrap it just for that - the later telemetry
> > work
> > from this year doesn't depend on jansson. Then again, the
> > vm_power_manager
> > example also uses it too...]. It's probably something that would be
> > especially useful for software dependencies that aren't normally
> > packaged.
> > 
> > I've added techboard on CC to previous reply, so hopefully we'll get
> > some
> > thoughts from others.
> > 
> 
> A buggy C compiler might generate buggy code, and the compiler induced bugs may not be caught during development (but hopefully during testing). I have seen this happen, and I still consider it a realistic scenario. This is the strongest argument for using a trusted version of the C compiler, which is supported by the popular GNU/Linux distributors (Red Hat etc.), or sufficiently vetted to be included in the Crosstool-NG project, or similar.
> 
> Meson is a relatively simple tool, so I personally wouldn't mind overwriting the distro-supported version on our build systems with a new version. (I haven't worked much with Meson, but assume that the new version of Meson is backwards compatible with its earlier versions.)
> 
> In short, my primary concern is: What could realistically go wrong if the required version of Meson is buggy?
> 
> Bruce, you have worked for quite a while with Meson/Ninja by now, so perhaps you can assess this risk based on your experience.
> 
I'd say the risk in this case is small, especially since I see that 0.56 of
meson is well under way for development and may well be released before
DPDK 20.11. Generally backwards compatibilty of meson is excellent as they
have comprehensive test suite for all features.

Rather than any bugginess, my concern was purely requiring people to update
meson using "pip3", but I suppose that's not really a big deal, and when
using pip update it defaults to just updating the copy for the local user,
not system-wide.

Updating to a later meson will give us access to a few other nice features
we can use also (from earlier releases than 0.55), such as support for
"break" and "continue" keywords in loops, which can simplify out lib or
driver building code, perhaps, or the "console" parameter for custom
targets which should improve the output visibility when builing our docs.

/Bruce

Re: [dpdk-dev] Meson Minimum Version

[Morten Brørup]

> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson
> Sent: Friday, September 25, 2020 10:41 AM
> To: Morten Brørup
> 
> On Fri, Sep 25, 2020 at 09:31:53AM +0200, Morten Brørup wrote:
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce
> Richardson
> > > Sent: Thursday, September 24, 2020 5:43 PM
> > >
> > > On Thu, Sep 24, 2020 at 03:32:41PM +0000, John Alexander wrote:
> > > >    Hi,
> > > >    Regarding the subproject local patch support, yes, it's only
> > > supported
> > > >    since Meson 0.55:
> > > >    https://mesonbuild.com/Wrap-dependency-system-manual.html We
> pip
> > > >    installed 0.55 Meson.
> > > >    I have a number of subsequent patches that depend on this
> > > particular
> > > >    pthreads library to advance the Windows DPDK support. Locally,
> we
> > > have
> > > >    testpmd (minus mmap'd external memory currently) running
> against
> > > the
> > > >    Intel i40e PMD (XL710 4x10Gbps SPF+ NIC) on Windows on our
> local
> > > DPDK
> > > >    fork (based off 20.08-rc2 using Microsoft's latest NetUIO
> driver).
> > > We
> > > >    have 47 of the 51 RTE libraries building and have had l2fwd,
> > > l3fwd,
> > > >    ipv4_multicast and almost all of the regression tests
> > > compiling+linking
> > > >    too. I'd like to push as much of the Windows EAL work we've
> done
> > > >    upstream if I can (after a bit of tidying up :).
> > > >    I've also coded up a meson build patch for the Jansson JSON
> parser
> > > used
> > > >    by the RTE metrics library (the config.h generation was quite
> > > fiddly!)
> > > >    That's ready to go. We get nice meson syntax as follows to
> specify
> > > a
> > > >    fallback if the library isn't installed locally:
> > > >    jansson = dependency('jansson', required: false, fallback :
> > > ['jansson',
> > > >    'jansson_static_dep'])
> > > >    I believe the meson command line enables disabling fallbacks
> if
> > > people
> > > >    would prefer not to use them (--wrap-mode=nofallback).
> > > >    Kind regards,
> > > >    John.
> > >
> > > Hi again, John,
> > >
> > > thanks for the full reply - the work you have sounds really good,
> and
> > > the
> > > possibilities using the wrap support are definitely of interest.
> > > [Though
> > > since jansson is only used for the legacy parts of the telemetry
> > > library
> > > I'm not sure we want to wrap it just for that - the later telemetry
> > > work
> > > from this year doesn't depend on jansson. Then again, the
> > > vm_power_manager
> > > example also uses it too...]. It's probably something that would be
> > > especially useful for software dependencies that aren't normally
> > > packaged.
> > >
> > > I've added techboard on CC to previous reply, so hopefully we'll
> get
> > > some
> > > thoughts from others.
> > >
> >
> > A buggy C compiler might generate buggy code, and the compiler
> induced bugs may not be caught during development (but hopefully during
> testing). I have seen this happen, and I still consider it a realistic
> scenario. This is the strongest argument for using a trusted version of
> the C compiler, which is supported by the popular GNU/Linux
> distributors (Red Hat etc.), or sufficiently vetted to be included in
> the Crosstool-NG project, or similar.
> >
> > Meson is a relatively simple tool, so I personally wouldn't mind
> overwriting the distro-supported version on our build systems with a
> new version. (I haven't worked much with Meson, but assume that the new
> version of Meson is backwards compatible with its earlier versions.)
> >
> > In short, my primary concern is: What could realistically go wrong if
> the required version of Meson is buggy?
> >
> > Bruce, you have worked for quite a while with Meson/Ninja by now, so
> perhaps you can assess this risk based on your experience.
> >
> I'd say the risk in this case is small, especially since I see that
> 0.56 of
> meson is well under way for development and may well be released before
> DPDK 20.11. Generally backwards compatibilty of meson is excellent as
> they
> have comprehensive test suite for all features.
> 

Thank you for the qualified risk assessment, Bruce.

> Rather than any bugginess, my concern was purely requiring people to
> update
> meson using "pip3", but I suppose that's not really a big deal, and
> when
> using pip update it defaults to just updating the copy for the local
> user,
> not system-wide.
> 
> Updating to a later meson will give us access to a few other nice
> features
> we can use also (from earlier releases than 0.55), such as support for
> "break" and "continue" keywords in loops, which can simplify out lib or
> driver building code, perhaps, or the "console" parameter for custom
> targets which should improve the output visibility when builing our
> docs.
> 
> /Bruce

I vote for requiring the later Meson version.

-Morten

Re: [dpdk-dev] Meson Minimum Version

[Dmitry Kozlyuk]

On Fri, 25 Sep 2020 09:41:22 +0100, Bruce Richardson wrote:
> On Fri, Sep 25, 2020 at 09:31:53AM +0200, Morten Brørup wrote:
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson
[snip]
> > In short, my primary concern is: What could realistically go wrong if the required version of Meson is buggy?
> > 
> > Bruce, you have worked for quite a while with Meson/Ninja by now, so perhaps you can assess this risk based on your experience.
> >   
> I'd say the risk in this case is small, especially since I see that 0.56 of
> meson is well under way for development and may well be released before
> DPDK 20.11. Generally backwards compatibilty of meson is excellent as they
> have comprehensive test suite for all features.
>
> Rather than any bugginess, my concern was purely requiring people to update
> meson using "pip3", but I suppose that's not really a big deal, and when
> using pip update it defaults to just updating the copy for the local user,
> not system-wide.

Speaking for Windows, at least twice this year there were incompatibilities
between _minor_ versions of Meson, due to admitted bugs in Meson. However,
IMO this is an argument for using just _exact_ version, not necessarily an old
one. Pip facilitates this better than OS package manager, because developer
controls the version and can easily switch, regardless of distro updates.
Thus, John's upgrade suggestion and transition to pip both look reasonable.

Re: [dpdk-dev] Meson Minimum Version

[Bruce Richardson]

On Fri, Sep 25, 2020 at 12:19:33PM +0300, Dmitry Kozlyuk wrote:
> On Fri, 25 Sep 2020 09:41:22 +0100, Bruce Richardson wrote:
> > On Fri, Sep 25, 2020 at 09:31:53AM +0200, Morten Brørup wrote:
> > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson
> [snip]
> > > In short, my primary concern is: What could realistically go wrong if the required version of Meson is buggy?
> > > 
> > > Bruce, you have worked for quite a while with Meson/Ninja by now, so perhaps you can assess this risk based on your experience.
> > >   
> > I'd say the risk in this case is small, especially since I see that 0.56 of
> > meson is well under way for development and may well be released before
> > DPDK 20.11. Generally backwards compatibilty of meson is excellent as they
> > have comprehensive test suite for all features.
> >
> > Rather than any bugginess, my concern was purely requiring people to update
> > meson using "pip3", but I suppose that's not really a big deal, and when
> > using pip update it defaults to just updating the copy for the local user,
> > not system-wide.
> 
> Speaking for Windows, at least twice this year there were incompatibilities
> between _minor_ versions of Meson, due to admitted bugs in Meson. However,
> IMO this is an argument for using just _exact_ version, not necessarily an old
> one. Pip facilitates this better than OS package manager, because developer
> controls the version and can easily switch, regardless of distro updates.
> Thus, John's upgrade suggestion and transition to pip both look reasonable.
> 

Seems that meson must be a bit more fragile on windows then, which is a
pity (and perhaps their regression tests aren't as good as I thought).
On Linux, since version 0.40 I think only one version, 0.47.0, caused an
issue for us, which was fixed in 0.47.1.
However, having a recommended version to use can work too.

[dpdk-dev] Meson Minimum Version

[John Alexander]

Hi,

I've submitted a patch that uses new features of Meson, specifically the directory patch aspect of the subproject feature.  This requires a minimum Meson version of 0.55.0.  How do we go about getting the community to accept a more recent version of Meson and getting the Travis server upgraded too so the CI builds succeed?

Patch link for reference: http://patches.dpdk.org/patch/78675/

Kind Regards,
John Alexander.

Re: [dpdk-dev] Meson Minimum Version

[Bruce Richardson]

On Thu, Sep 24, 2020 at 02:22:03PM +0000, John Alexander wrote:
> Hi,
> 
> I've submitted a patch that uses new features of Meson, specifically the directory patch aspect of the subproject feature.  This requires a minimum Meson version of 0.55.0.  How do we go about getting the community to accept a more recent version of Meson and getting the Travis server upgraded too so the CI builds succeed?
> 
> Patch link for reference: http://patches.dpdk.org/patch/78675/
> 
Hi John,

from what I understand the specific dependency on 0.55 is the support for
local patchfiles for the wrapped software, and that previous versions only
supported using patches pulled remotely - is that correct? 

While I'm in favour of incrementing the minimum meson version in general,
since 0.55 is the very latest version I am worried about any impacts that
might have, since it will basically mean that everyone building DPDK has to
pull meson from pip rather than being able to use a distro-supplied
version. Updating to something a little less recent would be more my
preference.

Then again, using the wrap system to pull in dependencies seems something
really good to have, so maybe the initial pain of requiring a recent meson
is worth it!

Thoughts from others?

Regards,
/Bruce

Re: [dpdk-dev] Meson Minimum Version

[Bruce Richardson]

On Thu, Sep 24, 2020 at 02:22:03PM +0000, John Alexander wrote:
> Hi,
> 
> I've submitted a patch that uses new features of Meson, specifically the directory patch aspect of the subproject feature.  This requires a minimum Meson version of 0.55.0.  How do we go about getting the community to accept a more recent version of Meson and getting the Travis server upgraded too so the CI builds succeed?
> 
> Patch link for reference: http://patches.dpdk.org/patch/78675/
> 
> Kind Regards,
> John Alexander.

Hi John,

this meson version change came up for discussion at the last DPDK technical
board meeting, and some concerns were expressed about the jump in version
and how it might impact those trying to package DPDK.

However, looking at your proposed patch, I wonder though if we really need
to globally bump the meson version, and whether we can limit the
requirements to just windows builds - which is what your patch targets.
Would the following change to your patch work for you? It keeps the minimum
meson version at 0.47.1 but then later does a windows-specific version
check, printing out an error message if requirements not met?

/Bruce

$ git diff
diff --git a/config/meson.build b/config/meson.build
index 69f2aeb60..fd48c9828 100644
--- a/config/meson.build
+++ b/config/meson.build
@@ -14,6 +14,11 @@ foreach env:supported_exec_envs
        set_variable('is_' + env, exec_env == env)
 endforeach

+# for windows, we need meson 0.55
+if is_windows and meson.version().version_compare('< 0.55')
+       error('Require meson 0.55 to build on windows')
+endif
+
 # MS linker requires special treatment.
 # TODO: use cc.get_linker_id() with Meson >= 0.54
 is_ms_linker = is_windows and (cc.get_id() == 'clang')
diff --git a/meson.build b/meson.build
index 9e061c73b..7dba3264e 100644
--- a/meson.build
+++ b/meson.build
@@ -8,7 +8,7 @@ project('DPDK', 'C',
                files('VERSION')).stdout().strip(),
        license: 'BSD',
        default_options: ['buildtype=release', 'default_library=static'],
-       meson_version: '>= 0.55.0'
+       meson_version: '>= 0.47.1'
 )

 # set up some global vars for compiler, platform, configuration, etc.

Re: [dpdk-dev] Meson Minimum Version

[John Alexander]

> On Thu, Sep 24, 2020 at 02:22:03PM +0000, John Alexander wrote:
> > Hi,
> >
> > I've submitted a patch that uses new features of Meson, specifically the
> directory patch aspect of the subproject feature.  This requires a minimum
> Meson version of 0.55.0.  How do we go about getting the community to
> accept a more recent version of Meson and getting the Travis server
> upgraded too so the CI builds succeed?
> >
> > Patch link for reference: http://patches.dpdk.org/patch/78675/
> >
> > Kind Regards,
> > John Alexander.
> 
> Hi John,
> 
> this meson version change came up for discussion at the last DPDK technical
> board meeting, and some concerns were expressed about the jump in
> version and how it might impact those trying to package DPDK.
> 
> However, looking at your proposed patch, I wonder though if we really need
> to globally bump the meson version, and whether we can limit the
> requirements to just windows builds - which is what your patch targets.
> Would the following change to your patch work for you? It keeps the
> minimum meson version at 0.47.1 but then later does a windows-specific
> version check, printing out an error message if requirements not met?
> 
> /Bruce
> 
> $ git diff
> diff --git a/config/meson.build b/config/meson.build index
> 69f2aeb60..fd48c9828 100644
> --- a/config/meson.build
> +++ b/config/meson.build
> @@ -14,6 +14,11 @@ foreach env:supported_exec_envs
>         set_variable('is_' + env, exec_env == env)  endforeach
> 
> +# for windows, we need meson 0.55
> +if is_windows and meson.version().version_compare('< 0.55')
> +       error('Require meson 0.55 to build on windows') endif
> +
>  # MS linker requires special treatment.
>  # TODO: use cc.get_linker_id() with Meson >= 0.54  is_ms_linker =
> is_windows and (cc.get_id() == 'clang') diff --git a/meson.build b/meson.build
> index 9e061c73b..7dba3264e 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -8,7 +8,7 @@ project('DPDK', 'C',
>                 files('VERSION')).stdout().strip(),
>         license: 'BSD',
>         default_options: ['buildtype=release', 'default_library=static'],
> -       meson_version: '>= 0.55.0'
> +       meson_version: '>= 0.47.1'
>  )
> 
>  # set up some global vars for compiler, platform, configuration, etc.
> 

Hi Bruce,

Thanks for the workaround suggestion.  That certainly works for me.

Kind Regards,
John Alexander.