: None
___
Follow-up Comments:
---
Date: Thu 08 Feb 2024 02:01:44 AM UTC By: Collin Funk
Hello, I believe I found a bug in the way that the $(info ...) function is
processed by GNU Make. I noti
Follow-up Comment #1, bug#65273 (group make):
I was able to reproduce this on a FreeBSD VM. The GNU Make in ports is version
4.3 and does not output the warnings. When using gmake from master they are
outputted. On a separate note, FreeBSD fails when building in maintainer mode
due to a #warning p
Follow-up Comment #2, bug#65273 (group make):
Finally got around to looking into this. From what I can tell it was an
intentional change from commit 03ecd94488b85adc38746ec3e7c2a297a522598e. The
previous commit doesn't warn and one referenced onward can be controlled with
--warn=(ignore|warn|error
Follow-up Comment #4, bug#65273 (group make):
[comment #3 comment #3:]
> It's usually a good idea to check the NEWS file for things that might cause
differences in behavior
Thanks. I'll do that next time first. :)
I grep'd for the error message and found it through git blame so it didn't
take too
Follow-up Comment #7, bug#65273 (group make):
[comment #6 comment #6:]
> Leaving these checks disabled by default is not a good solution since the
very people who need this help most, will not benefit from them.
I agree. It took me a while to understand some of the GNU Make extensions a
few years
,
etc. macros are checked. Feel free to reorder things if you'd like.
CollinFrom 9926caaa85919844de983d2c7f1b54b2debe2f08 Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Sat, 6 Apr 2024 19:44:23 -0700
Subject: [PATCH] Fix gcc SIZE_MAX redefined warnings.
* src/makeint.h: Include inttypes.h an
Paul Smith writes:
> On Fri, 2025-06-27 at 14:31 +0200, wrotycz wrote:
>> > Of course none of this is very relevant to the issue under
>> > discussion.
>>
>> I'm lost now.
>
> What I'm trying to say is that the exact number of jobs used as a
> default is not really that important. I have no pro
Paul Smith writes:
> But I agree with, and others have requested that, parallelism being
> limited in some way by available _memory_ and not just available CPU:
> this seems very reasonable. The fly in the ointment is that, even
> moreso than CPU, memory is not allocated up-front and by the time