Current state of meson

[Angel Pons]

Dear flashrom community,

Currently, flashrom has support for two different build systems: the
traditional Makefile-based approach, and meson. The latter was
introduced not too long ago [1] to be used by the fwupd project.
However, as far as I am concerned, it is currently not used for
build-testing on upstream, and is thus prone to breakage. As a result,
both build systems need to be kept in sync manually, which is an
additional maintenance burden. On top of that, it appears to be that
no one has been working on addressing this problem upstream.

In addition, looks like the Debian folks started using meson as well.
Looks like binaries built using meson do not work correctly, e.g., the
`-o` command-line option is unusable:

$ flashrom -p dummy -o logfile.txt
    flashrom v1.2 on Linux 5.2.0-2-amd64 (x86_64)
    flashrom is free software, get the source code at https://flashrom.org

Log file not supported in standalone mode. Aborting.
    Please run "flashrom --help" for usage info.

This problem can also be reproduced when building with meson on Arch
Linux, so it is not specific to Debian. Needless to say, binaries
built with the Makefile are unaffected.

So, given that meson produces broken executables and nobody seems to
be actively taking care of it, what should we do with it? Is anyone
interested in improving and maintaining the meson integration? All
suggestions are welcome.

Best regards,

Angel

[1]: https://review.coreboot.org/31248

[Jonathan A. Kollasch]

On Mon, May 25, 2020 at 11:20:21PM +0000, Angel Pons wrote:
> So, given that meson produces broken executables and nobody seems to
> be actively taking care of it, what should we do with it? Is anyone
> interested in improving and maintaining the meson integration? All
> suggestions are welcome.

Remove meson support.  Meson is no less broken than our home-grown
Makefiles.

Jonathan

[Richard Hughes]

On Tue, 26 May 2020 at 03:27, Jonathan A. Kollasch
 wrote:
> Remove meson support.

Removing meson support from flashrom would mean dropping the fwupd
plugin that uses libflashrom; we have to build flashrom from a
subproject as very often we're depending the very latest API
additions.
> Meson is no less broken than our home-grown Makefiles.

Can you substantiate that?

Richard.

[Richard Hughes]

On Tue, 26 May 2020 at 00:20, Angel Pons  wrote:
> So, given that meson produces broken executables and nobody seems to
> be actively taking care of it

Errr, I am taking care of it. Is it broken now?

Richard.

[Angel Pons]

Hi Richard, Jonathan, and everyone else,

On Tue, May 26, 2020 at 12:00 PM Richard Hughes  wrote:
> On Tue, 26 May 2020 at 00:20, Angel Pons  wrote:
> > So, given that meson produces broken executables and nobody seems to
> > be actively taking care of it
>
> Errr, I am taking care of it. Is it broken now?

Well, as I stated previously, flashrom built with meson results in the
`-o` option not working at all. When helping others via IRC, we
recommend fetching flashrom logs using that option so that no messages
get lost, so not being able to rely on it is rather inconvenient.

I can see [1] that you have two changes on gerrit, one of which is
currently not submittable due to merge conflicts and has not been
touched in two months. As far as I can tell, that's it. Are there any
future plans for meson, such as making Jenkins build-test it? Edward
O'Callaghan is working on unit testing [2], and it would be great if
Jenkins could actually run these tests alongside the usual build
tests. There isn't a thing such as too much coverage, or is there? :-P

Feel free to propose any ideas here in the mailing list, so that we
can discuss them beforehand. Working on something big without having
previously talked it through with the rest of the community is
dangerous: one can end up wasting lots of time working on something
that is then rejected, then emotions overflow and then everyone and
everything ends up on fire... I've had that happen several times and
it has always been extremely frustrating, so let's do it right this
time, shall we?  :-)

On Tue, May 26, 2020 at 12:03 PM Richard Hughes  wrote:
> On Tue, 26 May 2020 at 03:27, Jonathan A. Kollasch
>  wrote:
> > Remove meson support.
>
> Removing meson support from flashrom would mean dropping the fwupd
> plugin that uses libflashrom; we have to build flashrom from a
> subproject as very often we're depending the very latest API
> additions.

I believe dropping meson support should only be a last-resort measure,
so I brought up the topic on the mailing list to calmly and
respectfully exchange ideas about it and work towards improvement.
Let's be honest, we will never be able to make each and every being on
this planet completely happy, but we can surely attempt to find a
middle ground that is good enough for all of us, the flashrom
community.
> > Meson is no less broken than our home-grown Makefiles.
>
> Can you substantiate that?

Please refer to the aforementioned bug about `-o` not being usable
when building with meson. While the home-grown Makefiles may have
bugs, they have survived the test of time and should be considered the
official way to build flashrom, especially considering that Jenkins
relies on them to build-test flashrom patches.

If possible, I would consider turning meson into a wrapper around the
Makefiles, to eliminate redundancy. However, as I do not know a thing
about meson, I have no idea if such a thing is doable. As you seem to
be more familiar with meson than I am, what are your thoughts on this
idea? Is there a better way to handle that?
> Richard.

Best regards,

Angel

[1]: https://review.coreboot.org/q/owner:richard%2540hughsie.com
[2]: https://review.coreboot.org/41622

[Patrick Georgi]

Just chiming in on the bit I can contribute to:

Am Di., 26. Mai 2020 um 17:04 Uhr schrieb Angel Pons :
> Are there any future plans for meson, such as making Jenkins build-test it?

We should definitely do that. Also, we should run unit tests via Jenkins.
I can look into that.

Patrick

[Richard Hughes]

On Tue, 26 May 2020 at 16:03, Angel Pons  wrote:
> Well, as I stated previously, flashrom built with meson results in the
> `-o` option not working at all. When helping others via IRC, we
> recommend fetching flashrom logs using that option so that no messages
> get lost, so not being able to rely on it is rather inconvenient.

Is there a bug open? Meson defines -DSTANDALONE in the top level,
perhaps incorrectly.

Something like

+++ meson.build
@@ -415,7 +415,6 @@ executable(
   ],
   c_args : [
     cargs,
-    '-DSTANDALONE',
     '-DCONFIG_DEFAULT_PROGRAMMER=PROGRAMMER_INVALID',
     '-DCONFIG_DEFAULT_PROGRAMMER_ARGS=""',
   ],

Should fix this, although I can't remember the reason we used it in
the first place. There is no documentation of the expected defines, so
I might have got it wrong initially. If so, mea culpa.

I'm on PTO this week looking after kids, so I can't do a proper gerrit
review until next week. In the meantime, if someone else wants do that
for me I'd really appreciate the help.
> > > Meson is no less broken than our home-grown Makefiles.
> >
> > Can you substantiate that?
>
> Please refer to the aforementioned bug about `-o` not being usable
> when building with meson. While the home-grown Makefiles may have
> bugs, they have survived the test of time

Have you tried to build flashrom on Debian or Fedora using the
built-in makefiles? They're fine for building the software locally on
x86, but not much more.
> If possible, I would consider turning meson into a wrapper around the
> Makefiles, to eliminate redundancy.

That's not how meson works at all. The meson build system won't "wrap"
any other build system. You'll also notice the size of the meson files
compared to the size of the Makefiles; meson is a chance to get rid of
a lot of compat cruft and build projects with a specific DSL. On the
converse, you can use make to build the project using meson although I
think a few people might have problems with a python dep for build.

Richard.

[Stefan Tauner]

On Tue, 26 May 2020 19:20:47 +0100
Richard Hughes  wrote:
> Have you tried to build flashrom on Debian or Fedora using the
> built-in makefiles? They're fine for building the software locally on
> x86, but not much more.

The makefile is able to build flashrom on about any operating system
there is (including all BSDs, Windows, AppleOS, Solaris) for all
architectures (with the right programmers enabled if need be) -
natively and with cross compilers.
At least it used to when I stopped maintaining.

[Carl-Daniel Hailfinger]

On 26.05.20 20:27, Stefan Tauner wrote:
> On Tue, 26 May 2020 19:20:47 +0100
> Richard Hughes  wrote:
> > Have you tried to build flashrom on Debian or Fedora using the
> > built-in makefiles? They're fine for building the software locally on
> > x86, but not much more.
>
> The makefile is able to build flashrom on about any operating system
> there is (including all BSDs, Windows, AppleOS, Solaris) for all
> architectures (with the right programmers enabled if need be) -
> natively and with cross compilers.
> At least it used to when I stopped maintaining.

AFAIK that is still the case.

AFAICS the classic Makefile has all the features Meson has (even
libflashrom), but not the other way round.

An interesting test case would be to reproducibly build flashrom and
libflashrom with both meson and Makefile, and then check if any
differences arise. Any such difference could then be upgraded to a CI
failure.

Regards,
Carl-Daniel

[David Hendricks]

> Well, as I stated previously, flashrom built with meson results in the
> `-o` option not working at all. When helping others via IRC, we
> recommend fetching flashrom logs using that option so that no messages
> get lost, so not being able to rely on it is rather inconvenient.

Ouch... Yeah, that shouldn't happen.
> I can see [1] that you have two changes on gerrit, one of which is
> currently not submittable due to merge conflicts and has not been
> touched in two months.

To be fair, that's not a lot of time when we're talking about flashrom...
> Are there any
> future plans for meson, such as making Jenkins build-test it? Edward
> O'Callaghan is working on unit testing [2], and it would be great if
> Jenkins could actually run these tests alongside the usual build
> tests. There isn't a thing such as too much coverage, or is there? :-P

Patrick already chimed in, w.r.t. Jenkins. Automating some QA has been
on my todo list for a while, and I'm in between jobs at the moment so
I'll finally have a bit of time to work on it :-)

Overall I'd like to keep meson support working for fwupd. Like
ChromeOS it's a valuable user that provides development, hardware
support, and testing on realworld hardware at the cost of a few
relatively minor bumps. It's better to work with those communities
rather than them forking or reinventing flashrom.

[Richard Hughes]

On Wed, 27 May 2020 at 05:41, David Hendricks  wrote:
> > currently not submittable due to merge conflicts and has not been
> > touched in two months.
>
> To be fair, that's not a lot of time when we're talking about flashrom...

Also we're in the middle of a global pandemic, with a lot of us
juggling childcare, work and all our other commitments.

Richard.

[Richard Hughes]

On Wed, 27 May 2020 at 05:41, David Hendricks  wrote:
> > `-o` option not working at all. When helping others via IRC, we
> > recommend fetching flashrom logs using that option so that no messages
> > get lost, so not being able to rely on it is rather inconvenient.
>
> Ouch... Yeah, that shouldn't happen.

I've created a trivial gerrit patch here, feedback welcome:
https://review.coreboot.org/c/flashrom/+/42230

Richard