From: Patrick Steinhardt <ps@pks.im>
To: "Martin Storsjö" <martin@martin.st>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v2] meson: Tolerate errors from git ls-files --deduplicate
Date: Fri, 1 Aug 2025 11:45:29 +0200 [thread overview]
Message-ID: <aIyMuUZaARaTpmOh@pks.im> (raw)
In-Reply-To: <226b2a31-6220-4a4e-d0bf-3ad80c3be9a@martin.st>
On Fri, Aug 01, 2025 at 12:42:52PM +0300, Martin Storsjö wrote:
> On Fri, 1 Aug 2025, Patrick Steinhardt wrote:
>
> > On Fri, Aug 01, 2025 at 10:56:22AM +0300, Martin Storsjö wrote:
> > > index 9bc1826cb6..9b519e6eed 100644
> > > --- a/meson.build
> > > +++ b/meson.build
> > > @@ -694,9 +694,12 @@ third_party_excludes = [
> > >
> > > headers_to_check = []
> > > if git.found() and fs.exists(meson.project_source_root() / '.git')
> > > - foreach header : run_command(git, '-C', meson.project_source_root(), 'ls-files', '--deduplicate', '*.h', third_party_excludes, check: true).stdout().split()
> > > - headers_to_check += header
> > > - endforeach
> > > + ls_headers = run_command(git, '-C', meson.project_source_root(), 'ls-files', '--deduplicate', '*.h', third_party_excludes, check: false)
> > > + if ls_headers.returncode() == 0
> > > + foreach header : ls_headers.stdout().split()
> > > + headers_to_check += header
> > > + endforeach
> > > + endif
> > > endif
> >
> > Yup, this looks reasonable to me. We could have an `else` branch that
> > warns about the command failing, for example like this:
> >
> > warning("could not find headers: " + ls_headers.stderr())
>
> This would work - however the output from ls_headers.stderr() is fairly long
> (if you try running e.g. "git ls-files --foobar", you'll get a 37 line
> listing of potential options); it's rather distracting for what's otherwise
> a fairly minor build configuration issue.
>
> Using ls_headers.stderr().split('\n')[0] works and just gets us this:
>
> ../meson.build:703: WARNING: could not find headers: error: unknown option `deduplicate'
>
> However I wonder if it's worth it, or if it just makes the meson file
> potentially more brittle? (E.g. what if split() returns an array of 0
> elements? Not sure if that's possible though...)
True. Maybe we can just not include stderr at all but say:
could not list headers, disabling static analysis targets
That's probably sufficient.
Patrick
next prev parent reply other threads:[~2025-08-01 9:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-31 12:15 [PATCH] meson: Check whether git is new enough to support ls-files --deduplicate Martin Storsjö
2025-08-01 5:27 ` Patrick Steinhardt
2025-08-01 7:55 ` Martin Storsjö
2025-08-01 7:56 ` [PATCH v2] meson: Tolerate errors from git " Martin Storsjö
2025-08-01 9:23 ` Patrick Steinhardt
2025-08-01 9:42 ` Martin Storsjö
2025-08-01 9:45 ` Patrick Steinhardt [this message]
2025-08-01 10:24 ` Martin Storsjö
2025-08-01 10:25 ` [PATCH v3] " Martin Storsjö
2025-08-01 14:44 ` Patrick Steinhardt
2025-08-01 15:59 ` [PATCH v2] " Junio C Hamano
2025-08-01 16:27 ` Martin Storsjö
2025-08-01 16:28 ` [PATCH v4] " Martin Storsjö
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=aIyMuUZaARaTpmOh@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=martin@martin.st \
/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).