> I think there's a better way to handle this than the one you suggest Let's not blame Sam for my patch, with its gruesome returning, and hence presumably exporting, of some strdup()d boilerplate to stop the caller from crashing.
> why does this prevent doing any more testing? I expect he didn't want to make his builds dependent on the first "completely botched fix" some rando halfheartedly suggested. Said Morton's Gambit<https://m.slashdot.org/story/23412> has, though, kept me testing the latest code, with nothing further to report. I for one am relieved that Sam made time to tell us that this recent change has bitten a second code base. Although the minimal reproducer is tiny and probably seems obvious, it took me some hours to extract it from the production code that broke. That might have given me a work around, other than patching make, but I wouldn't wish that extra work on Sam. ________________________________ From: Bug-make <bug-make-bounces+martin.dorey=hds....@gnu.org> on behalf of Paul Smith <psm...@gnu.org> Sent: Tuesday, September 6, 2022 07:58 To: Sam James <s...@gentoo.org> Cc: bug-make@gnu.org <bug-make@gnu.org> Subject: Re: New release of GNU make ***** EXTERNAL EMAIL ***** On Mon, 2022-09-05 at 03:47 +0100, Sam James wrote: > I started testing master recently and hit > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsavannah.gnu.org%2Fbugs%2F%3F63016&data=05%7C01%7CMartin.Dorey%40hitachivantara.com%7Cb276198202664b4c7f8308da90184aa9%7C18791e1761594f52a8d4de814ca8284a%7C0%7C0%7C637980731257414132%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BWi4lSzo%2FL9xA0MNGjdeFLD4qcg0CAQmV1ImJfc4Dd8%3D&reserved=0 > which prevented doing any more testing. Just curious: why does this prevent doing any more testing? That issue needs to be carefully considered. In the previous release, B would not be exported to the $(shell ...) function and so this issue doesn't come up. In the new release, it is and it does. I think there's a better way to handle this than the one you suggest but I will need to look more closely at it. I agree that limiting the check to target_environment() was too optimistic on my part.
