{"thread":{"id":"64654","subject":"[PATCH] rust: build correctly without GNU sed","startedAt":"2025-12-18T23:26:13Z","lastAt":"2025-12-19T06:24:37Z","messageCount":3,"participants":["D. Ben Knoble","Eric Sunshine","Patrick Steinhardt"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"532505","messageId":"a33f4e5118938300bcd5b2991feeee855a1c8f86.1766100330.git.ben.knoble+github@gmail.com","threadId":"64654","inReplyTo":null,"subject":"[PATCH] rust: build correctly without GNU sed","fromName":"D. Ben Knoble","fromEmail":"ben.knoble+github@gmail.com","sentAt":"2025-12-18T23:25:44Z","receivedAt":"2025-12-18T23:26:13Z","isPatch":true,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"From e509b5b8be (rust: support for Windows, 2025-10-15), we check\ncargo's information to decide which library to build. However, that\ncheck mistakenly used \"sed -s\" (\"consider files as separate rather than\nas a single, continuous long stream\"), which is a GNU extension. The\nbuild thus fails on macOS with \"meson -Drust=enabled\", which comes with\nBSD-derived sed.\n\nInstead, use the intended \"sed -n\" and print the matching section of the\noutput. This failure mode likely went unnoticed on systems with GNU sed\n(common for developer machines and CI) because, in those instances, the\noutput being matched by case is the full cargo output (which either\ncontains the string \"-windows-\" or doesn't).\n\nHelped-by: Eric Sunshine <sunshine@sunshineco.com>\nHelped-by: Patrick Steinhardt <ps@pks.im>\nSigned-off-by: D. Ben Knoble <ben.knoble+github@gmail.com>\n---\n src/cargo-meson.sh | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/src/cargo-meson.sh b/src/cargo-meson.sh\nindex 3998db0435..38728a3711 100755\n--- a/src/cargo-meson.sh\n+++ b/src/cargo-meson.sh\n@@ -26,7 +26,7 @@\n \texit $RET\n fi\n \n-case \"$(cargo -vV | sed -s 's/^host: \\(.*\\)$/\\1/')\" in\n+case \"$(cargo -vV | sed -n 's/^host: \\(.*\\)$/\\1/p')\" in\n \t*-windows-*)\n \t\tLIBNAME=gitcore.lib;;\n \t*)\n-- \n2.52.0.rc0.365.g9bf09b728d.dirty\n\n"},{"id":"532512","messageId":"CAPig+cSJa8JQRBATOYoizE4-Li_zO5o4FkFR7okiVDYdndSWZQ@mail.gmail.com","threadId":"64654","inReplyTo":"a33f4e5118938300bcd5b2991feeee855a1c8f86.1766100330.git.ben.knoble+github@gmail.com","subject":"Re: [PATCH] rust: build correctly without GNU sed","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2025-12-19T00:53:10Z","receivedAt":"2025-12-19T00:53:22Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Thu, Dec 18, 2025 at 6:26 PM D. Ben Knoble\n<ben.knoble+github@gmail.com> wrote:\n> From e509b5b8be (rust: support for Windows, 2025-10-15), we check\n> cargo's information to decide which library to build. However, that\n> check mistakenly used \"sed -s\" (\"consider files as separate rather than\n> as a single, continuous long stream\"), which is a GNU extension. The\n> build thus fails on macOS with \"meson -Drust=enabled\", which comes with\n> BSD-derived sed.\n>\n> Instead, use the intended \"sed -n\" and print the matching section of the\n> output. This failure mode likely went unnoticed on systems with GNU sed\n> (common for developer machines and CI) because, in those instances, the\n> output being matched by case is the full cargo output (which either\n> contains the string \"-windows-\" or doesn't).\n>\n> Helped-by: Eric Sunshine <sunshine@sunshineco.com>\n> Helped-by: Patrick Steinhardt <ps@pks.im>\n> Signed-off-by: D. Ben Knoble <ben.knoble+github@gmail.com>\n> ---\n> diff --git a/src/cargo-meson.sh b/src/cargo-meson.sh\n> @@ -26,7 +26,7 @@\n> -case \"$(cargo -vV | sed -s 's/^host: \\(.*\\)$/\\1/')\" in\n> +case \"$(cargo -vV | sed -n 's/^host: \\(.*\\)$/\\1/p')\" in\n>         *-windows-*)\n>                 LIBNAME=gitcore.lib;;\n\nThis change looks good to me. Thanks for tackling this.\n"},{"id":"532516","messageId":"aUTvneg9W-6ba4Ev@pks.im","threadId":"64654","inReplyTo":"a33f4e5118938300bcd5b2991feeee855a1c8f86.1766100330.git.ben.knoble+github@gmail.com","subject":"Re: [PATCH] rust: build correctly without GNU sed","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-12-19T06:24:29Z","receivedAt":"2025-12-19T06:24:37Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Thu, Dec 18, 2025 at 06:25:44PM -0500, D. Ben Knoble wrote:\n> From e509b5b8be (rust: support for Windows, 2025-10-15), we check\n> cargo's information to decide which library to build. However, that\n> check mistakenly used \"sed -s\" (\"consider files as separate rather than\n> as a single, continuous long stream\"), which is a GNU extension. The\n> build thus fails on macOS with \"meson -Drust=enabled\", which comes with\n> BSD-derived sed.\n> \n> Instead, use the intended \"sed -n\" and print the matching section of the\n> output. This failure mode likely went unnoticed on systems with GNU sed\n> (common for developer machines and CI) because, in those instances, the\n> output being matched by case is the full cargo output (which either\n> contains the string \"-windows-\" or doesn't).\n\nYeah, I guess that's what happened indeed. I seem to have confused \"-s\"\nfor \"--silent\" with \"-n\" when I wrote this.\n\n> Helped-by: Eric Sunshine <sunshine@sunshineco.com>\n> Helped-by: Patrick Steinhardt <ps@pks.im>\n\nI'd say that it was you two folks who figured this out, I didn't really\nhelp much :) But I won't complain.\n\n> Signed-off-by: D. Ben Knoble <ben.knoble+github@gmail.com>\n> ---\n>  src/cargo-meson.sh | 2 +-\n>  1 file changed, 1 insertion(+), 1 deletion(-)\n> \n> diff --git a/src/cargo-meson.sh b/src/cargo-meson.sh\n> index 3998db0435..38728a3711 100755\n> --- a/src/cargo-meson.sh\n> +++ b/src/cargo-meson.sh\n> @@ -26,7 +26,7 @@\n>  \texit $RET\n>  fi\n>  \n> -case \"$(cargo -vV | sed -s 's/^host: \\(.*\\)$/\\1/')\" in\n> +case \"$(cargo -vV | sed -n 's/^host: \\(.*\\)$/\\1/p')\" in\n>  \t*-windows-*)\n>  \t\tLIBNAME=gitcore.lib;;\n>  \t*)\n\nYup, this looks exactly like discussed. Thanks, the fix looks good to\nme!\n\nPatrick\n"}]}