Re: New release of GNU make

[Paul Smith]

On Tue, 2022-09-06 at 18:59 +0100, Sam James wrote:
> When we started testing in Gentoo (not unleashed onto users),
> we had several failures that looks liked this almost immediately.

I see, thanks.  I will look at this tonight.  Clearly this change
introduces too severe a regression to accept as-is.

Re: New release of GNU make

[Sam James]

> On 6 Sep 2022, at 15:58, Paul Smith  wrote:
> 
> On Mon, 2022-09-05 at 03:47 +0100, Sam James wrote:
>> I started testing master recently and hit
>> https://savannah.gnu.org/bugs/?63016
>> which prevented doing any more testing.
> 
> Just curious: why does this prevent doing any more testing?
> 

We usually try to test new versions of things before they come out
and build all packages against it.

When we started testing in Gentoo (not unleashed onto users),
we had several failures that looks liked this almost immediately.

This tends to be a sign of more to come if things fall out
very quickly.

We had:
- https://bugs.gentoo.org/867892 ("media-gfx/gif2png-2.5.14:0 - 
Makefile:: Recursive variable VERSION references itself (eventually). 
Stop.")
- https://bugs.gentoo.org/867895 ("dev-lang/mercury-22.01.1:0 - Recursive 
variable 'GRADESTRING' references itself (eventually). Stop.")
- https://bugs.gentoo.org/867904 ("games-simulation/simutrans-123.0.1-r1:0 - 
Makefile:: Recursive variable CFLAGS references itself (eventually). 
Stop.")

I didn't bother continuing given:
1. This happened so quickly and I suspect there'd be
many duplicates;
2. Dependencies failing to build makes it more awkward to test other
packages;
3. Any fix for this might end up influencing other results anyway,
so I'd need to test again once this issue is fixed.

If you think this is another issue, I can file
a separate, new bug.

Best,
sam


signature.asc
Description: Message signed with OpenPGP

Re: New release of GNU make

[Martin Dorey]

> 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 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  on behalf of 
Paul Smith 
Sent: Tuesday, September 6, 2022 07:58
To: Sam James 
Cc: 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%3F63016data=05%7C01%7CMartin.Dorey%40hitachivantara.com%7Cb276198202664b4c7f8308da90184aa9%7C18791e1761594f52a8d4de814ca8284a%7C0%7C0%7C637980731257414132%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=%2BWi4lSzo%2FL9xA0MNGjdeFLD4qcg0CAQmV1ImJfc4Dd8%3Dreserved=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.

Re: New release of GNU make

[Paul Smith]

On Mon, 2022-09-05 at 03:47 +0100, Sam James wrote:
> I started testing master recently and hit
> https://savannah.gnu.org/bugs/?63016
> 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.