Show 46 quoted lines
> Le 15 déc. 2025 à 10:28, Patrick Steinhardt <ps@pks.im> a écrit :
>
> On Fri, Dec 12, 2025 at 03:32:30PM -0500, Eric Sunshine wrote:
>>> On Fri, Dec 12, 2025 at 3:01 PM D. Ben Knoble
>>> <ben.knoble+github@gmail.com> wrote:
>>> I think it's due to e509b5b8be (rust: support for Windows, 2025-10-15)
>>> [relevant folks CC'd], where we assume sed can take "-s" (which AFAICT
>>> is a GNU extension). But perhaps "-n" was intended with a "p" flag on
>>> the substitution?
>>>
>>> I've been building with Rust enabled on Gentoo now for a minute and
>>> haven't hit any issues, but that's perhaps because the command is
>>> running with "-s" and not working as intended (yet still producing the
>>> expected results).
>>>
>>> The relevant snippet is this (reformatted slightly by GMail, apologies):
>>>
>>> case "$(cargo -vV | sed -s 's/^host: \(.*\)$/\1/')" in
>>> *-windows-*) LIBNAME=gitcore.lib;;
>>> *) LIBNAME=libgitcore.a;;
>>> esac
>>>
>>> but "cargo -vV" produces something like
>>>
>>> cargo 1.89.0 (c24e10642 2025-06-23)
>>> [...]
>>> host: x86_64-apple-darwin
>>>
>>> (on my older system, on which I haven't tried the build; the failure
>>> is on my newer system with close-enough-to-the-same output). I'm sure
>>> you can see why I don't understand why we need GNU's "-s" ("consider
>>> files as separate rather than as a single, continuous long stream")
>>> here?
>>
>> Yup, that's a strange one. Indeed:
>>
>> sed -n 's/^host: \(.*\)$/\1/p'
>>
>> would be the correct way to do it, while also being compatible with
>> BSD-lineage `sed` (such as `sed` on macOS).
>
> Ah, indeed. Would one of you want to turn this into a patch?
>
> Thanks for the report!
>
> Patrick