[bug #65273] Potential bug in the info function?

[Collin Funk]

URL:
  <https://savannah.gnu.org/bugs/?65273>

 Summary: Potential bug in the info function?
   Group: make
   Submitter: collinfunk
   Submitted: Thu 08 Feb 2024 02:01:44 AM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.4.1
Operating System: POSIX-Based
   Fixed Release: None
   Triage Status: 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 noticed it building Emacs from master. With both Make
built from master and tag 4.4.1 building Emacs outputs a lot of undefined
variable references like so:

../src/verbose.mk:58: warning: invalid variable reference ' '
  CC   print.o
../src/verbose.mk:58: warning: invalid variable reference ' '
  CC   lread.o
../src/verbose.mk:58: warning: invalid variable reference ' '
  CC   emacs-module.o
../src/verbose.mk:58: warning: invalid variable reference ' '
  CC   syntax.o
../src/verbose.mk:58: warning: invalid variable reference ' '

The file that causes the warning can be found here:

https://git.savannah.gnu.org/cgit/emacs.git/tree/src/verbose.mk.in

This does not occur with GNU Make 4.3 packaged in Debian Stable. I'll try to
look for the cause a bit later but I am not too sure how the $(info ...)
function works. Hopefully I gave enough information to reproduce it. Thanks!







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65273>

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #65273] Potential bug in the info function?

[Collin Funk]

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 preprocecessor directive in sys/timeb.h. I've attached a
patch fixing the problem.

(file #55675)

___

Additional Item Attachment:

File name: 0001-maint-Don-t-include-sys-timeb.h-on-FreeBSD.patch Size:0 KB
   



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-374ad428f2bd97d03e9733e262e1a321118d5556.tar.gz


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #65273] Potential bug in the info function?

[Collin Funk]

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). Can you confirm that I am not mistaken? If not
then the Makefile should be pretty easy to fix for the Emacs people. Thanks.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #65273] Potential bug in the info function?

[Collin Funk]

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 long.

[comment #3 comment #3:]
> Unfortunately I can't think of a good way to continue to allow this to work,
other than simply disabling the warning by default which I'd really prefer to
not do.

I agree with your preference. The warning seems useful to catch actual bugs.
The Emacs Makefile was just written before it existed.

[comment #3 comment #3:]
> I wonder how common this particular little trick is, out in the world.

I'm surprised no one else has ran into it and reported it since the change is
a year old. I'll submit a bug or email the Emacs people about it later today.
I assume the goal was to make it output in the same way that ./configure
--enable-silent-rules would. Removing the whitespace would cause the output to
look different but would silence the warnings so they aren't interpreted as a
bug like I did. If I manage to think of a decent syntax for adding whitespace
I'll propose it on the mailing list. Thanks for the help! Feel free to mark
this as "Not a bug" if you'd like. I'm not sure how to on Savannah.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #65273] Potential bug in the info function?

[Collin Funk]

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 ago. I think the warnings would have helped me.

[comment #6 comment #6:]
> Of course we COULD add "special case" facilities for various projects'
special tricks but I'm not a fan of this approach.

Sounds like it would be a pain to maintain. Paul Eggert said the "$ " trick
was just for Emacs.
It was changed to your "$." trick yesterday and seems to be working fine so
far.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=68996

Thanks again for the help.



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Fix gcc SIZE_MAX redefined warnings.

[Collin Funk]

When compiling GNU Make from git master I get warnings that SIZE_MAX
is redefined. This patch fixes it.

This macro is defined by glibc in stdint.h/inttypes.h but
src/makeint.h checks for it after including limits.h.

I've just placed these headers under limits.h before any *_MIN, *_MAX,
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 and stdint.h before checking if
SIZE_MAX is defined.
---
 src/makeint.h | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/src/makeint.h b/src/makeint.h
index 5a553093..d65b0ce7 100644
--- a/src/makeint.h
+++ b/src/makeint.h
@@ -139,6 +139,13 @@ extern int errno;
 # include 
 #endif
 
+#if HAVE_INTTYPES_H
+# include 
+#endif
+#if HAVE_STDINT_H
+# include 
+#endif
+
 #ifndef PATH_MAX
 # ifdef MAXPATHLEN
 #  define PATH_MAX  MAXPATHLEN
@@ -279,13 +286,6 @@ char *strerror (int errnum);
 #endif  /* !ANSI_STRING.  */
 #undef ANSI_STRING
 
-#if HAVE_INTTYPES_H
-# include 
-#endif
-#if HAVE_STDINT_H
-# include 
-#endif
-
 #if HAVE_STRINGS_H
 # include   /* Needed for strcasecmp / strncasecmp.  */
 #endif
-- 
2.44.0

Re: Autodetect processing units with -j

[Collin Funk]

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 problem saying that
> the default number (should we decide to use it) would be 1 * ncpu.  I
> would not say, though, that it's completely obvious that this value is
> always the best in every situation, which was your original claim.
>
> The important, difficult, and time-consuming thing is to decide
> (a) whether to make the change in the first place, and, if so, (b) what
> the new behavior of the various options should be.
>
> There are two issues here: one is that "-j" has a poor choice for
> default behavior because it can cause hundreds of jobs to be spawned
> very quickly and bring the system to a standstill, which is bad.
>
> The other is that it's difficult to set a generic value for "-j" (say
> in a MAKEFLAGS environment variable, or even in the makefile itself)
> that works across a variety of systems with different CPU counts.
>
> Is it sufficient to solve the second issue without addressing the
> first?  If so you could imagine supporting more complex values for
> "-j"; for example, "-jn" means "number of CPUs", while "-j2n" means
> "twice the number of CPUs", or something like that.  This is a
> backward-compatible change so it's not so controversial.
>
> If you really want to address the first issue, the default behavior of
> "-j" with no argument, then that's a change to long-standing behavior
> so needs to be considered carefully.

Just want to voice my support for Paul's reasoning.

Using a default value for '-j' would not work in every situation. For
example, the 'ninja' command (similar to 'make' but meant to be written
by some meta-build tool like 'cmake' or 'meson') it defaults to a high
number of jobs:

$ ninja --help 2>&1 | grep -- '-j'
  -j N run N jobs in parallel (0 means infinity) [default=18 on this 
system]

When compiling LLVM, this number of jobs will make my system run
out-of-memory while linking. And when my system runs out-of-memory, it
is not very graceful. It freezes until I reboot it using the power
button.

If one wants to add a default value because they know it will always
work with their system they can easily add this to their ~/.profile:

export GNUMAKEFLAGS="$((2 * `nproc`))"

Assuming this is the value they want (and 'nproc' from Coreutils).

Collin

Re: Autodetect processing units with -j

[Collin Funk]

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
> memory pressure gets significant it's very possible make has already
> spawned too many parallel jobs.  Also, detecting amount of memory in
> use vs. free is harder to do, even among different POSIX systems.
>
> Nevertheless, it would still be a useful feature IMO.

That sounds reasonable. But since we do not know how much memory will be
consumed by the parallel jobs, any limit will be a heuristic. There may
be some cases, like my LLVM example, which requires lots of memory to
link, where the default '-j' will need to be changed by the user. This
is fine with me though, as long as the heuristic is good enough for most
situations.

Regarding the lack of portable methods for getting the number of CPUs
and free/used memory, we are fully in agreement. It is a pain.

You may find lib/nproc.[ch] and lib/physmem.[ch] in Gnulib useful.

Collin