[bug #63157] Unlink temporary files.

Follow-up Comment #18, bug #63157 (project make): [comment #17 comment #17:] > Paul, if you decide to proceed with changes in comment 11, temp_stdin_fileno should probably be of type volatile sig_atomic_t, rather than int. Are you sure that's big enough? According to https://cplusplus.com/refere

[bug #63157] Unlink temporary files.

Follow-up Comment #19, bug #63157 (project make): It's probably not worth spending a lot of time ruminating on these things. The reality is that currently make does many non-handler-safe things in its signal handler, and there are Savannah bugs about hangs etc. while catching SIGINT which prove i

misinterpretation of shell $'...' escape form

Given the following Makefile, define newline endef define cmd1 thing1 thing2 endef help: echo '$(subst $(newline),'$$'\n'',$(cmd1))' .PHONY: help , on an Ubuntu 22.04 system, GNU Make 4.3, Bash 5.1.16(1), and the Makefile below, "make help" produces the following

Re: misinterpretation of shell $'...' escape form

On Sat, 2022-10-15 at 22:41 +0300, Poor Yorick wrote: > on an Ubuntu 22.04 system, GNU Make 4.3, Bash 5.1.16(1) GNU make, like all POSIX compliant makes, does not run bash. It runs the shell provided in the make variable (not the shell variable!) SHELL. That value is, by default, /bin/sh which i

[bug #63215] --shuffle=random doesn't properly initialize config.seed

Follow-up Comment #1, bug #63215 (project make): Using 0 here still gives a random shuffle because 0 means "generate a new random number". However you're right that this is not correct because it doesn't allow us to recreate the random value. Thanks for the note! __

[bug #63185] configure fails to detect getloadavg declaration on sun and aix.

Follow-up Comment #2, bug #63185 (project make): Instead of reverting the content in job.c, can you keep that content but add this: #if HAVE_SYS_LOADAVG_H #include #include #endif #ifndef HAVE_DECL_GETLOADAVG int getloadavg (double loadavg[], int nelem); #endif and see if that works?

[bug #63125] Automatic variables in Secondary Expansion don't work as documented

Update of bug #63125 (project make): Item Group: Bug => Enhancement ___ Follow-up Comment #6: I'm going to change this into an enhancement, to figure out how to make this comprehensible and "do

[bug #62936] Confusing description of chained rules in the manual

Follow-up Comment #1, bug #62936 (project make): I don't know why you say "you cannot update a non-existing file": make does this all the time! When you start make in a clean directory there are no object files, for example, and so those files are non-existing but yet of course make will still up

[bug #63219] Introduce a close function for loadable plugins.

URL: Summary: Introduce a close function for loadable plugins. Project: make Submitter: dgoncharov Submitted: Sun 16 Oct 2022 12:17:42 AM UTC Severity: 3 - Normal

[bug #63219] Introduce a close function for loadable plugins.

Additional Item Attachment, bug #63219 (project make): File name: sv63219.diff Size:6 KB File name: sv63219_test.diff Size:4 KB

[bug #63219] Introduce a close function for loadable plugins.

Follow-up Comment #1, bug #63219 (project make): Make allows a loadable plugin to implement a setup function. This patch adds the ability for a loadable plugin to optionally specify a close function. Make calls this close function before unloading the plugin. This close function can be used for c

[bug #63219] Introduce a close function for loadable plugins.

Follow-up Comment #2, bug #63219 (project make): This is the example from the manual extended with a close function #include #include #include #include #include #include int plugin_is_GPL_compatible; struct file { struct file *next; char *name; }; static struct file *files = N

[bug #63219] Introduce a close function for loadable plugins.

Follow-up Comment #3, bug #63219 (project make): If we are going to extend the API of the loadable modules, I think we will have to introduce API versions, because the new API will be binary-incompatible with the old one, and Make should refuse to load modules that are incompatible with the API fo