From: Bruce Richardson <bruce.richardson@intel.com>
To: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Cc: "Morten Brørup" <mb@smartsharesystems.com>,
"John Alexander" <John.Alexander@datapath.co.uk>,
dev@dpdk.org, techboard@dpdk.org
Subject: Re: [dpdk-dev] Meson Minimum Version
Date: Fri, 25 Sep 2020 10:22:57 +0100 [thread overview]
Message-ID: <20200925092257.GC923@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <20200925121933.517c645c@sovereign>
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.
next prev parent reply other threads:[~2020-09-25 9:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-24 15:32 John Alexander
2020-09-24 15:43 ` Bruce Richardson
2020-09-25 7:31 ` Morten Brørup
2020-09-25 8:41 ` Bruce Richardson
2020-09-25 8:58 ` Morten Brørup
2020-09-25 9:19 ` Dmitry Kozlyuk
2020-09-25 9:22 ` Bruce Richardson [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-09-24 14:22 John Alexander
2020-09-24 14:38 ` Bruce Richardson
2020-10-09 15:59 ` Bruce Richardson
2020-10-09 16:15 ` John Alexander
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200925092257.GC923@bricha3-MOBL.ger.corp.intel.com \
--to=bruce.richardson@intel.com \
--cc=John.Alexander@datapath.co.uk \
--cc=dev@dpdk.org \
--cc=dmitry.kozliuk@gmail.com \
--cc=mb@smartsharesystems.com \
--cc=techboard@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).