Re: [PATCH] src/main.c: Add -J to detect number of job slots based on nproc.

[DSB]

>
> Isn't nproc or nproc+1 too much?  On systems with hyper-threading,
> this will try using too many jobs, and might cause the system be
> significantly less responsive.  Maybe nproc/2 is a better default?
>

This is an interesting question and I suppose the answer depends on many
factors. At my organization we've actually gone the other direction and
default to -j (nproc * 2) on the theory that one of the two jobs is liable
to be sleeping on I/O at any given time. But this is very much a YMMV area
and the builtin default, if there was to be one at all, should be
conservative so nproc * 2 would be a bad choice.

Re: [bug #65533] gmake-4.4.1 has a performance regression: at least the nwchem project now builds much slower

[DSB]

 > ... remove all those .EXPORT_ALL_VARIABLES: settings.  This is just a
very bad idea.

Sorry for the side-track but in my experience exporting *any* make variable
is a bad idea. Where I work we maintain a "Make Bible" which says something
to the effect that the only time it makes sense to export a make variable
is if it's not _really_ a make variable. In other words this may be ok:

export PATH := $(PATH):/some/bin

Because $PATH isn't fundamentally a make variable, just a normal
environment variable we can manipulate in make syntax, but there's no
excuse for ever exporting a make variable that isn't originally an env var.
There are only two cases:

1. You want to pass it to a non-make process invoked from a recipe. This
falls into the exception above: it's not primarily a make variable or it
wouldn't be useful to the non-make process.

2. You want to pass it to a recursively-invoked make. In this case it's far
better to do so explicitly:

$(MAKE) FOO=bar ...

Both because it's more self-documenting and because it narrows the scope.
FOO will end up in the environment anyway since make automatically exports
command line overrides but only in that branch of the process tree.

An environment variable is the logical equivalent of a global variable in C
and suffers from all the same issues. Once you've exported a variable
you've lost control over who comes to depend on it so it becomes
exponentially harder to clean up the environment later. A good programmer
limits the number of global variables and no competent programmer would
make everything global. Same with the environment.

I understand these capabilities must be provided for POSIX and backward
compatibility but I think they should be deprecated. I might go so far as
to say so in the manual.

David

On Fri, Mar 29, 2024 at 1:54 PM Paul D. Smith 
wrote:

> Follow-up Comment #4, bug #65533 (group make):
>
> I cloned the nwchem git repository and my suspicions were correct.
>
> I see many, many instances of recursive variable assignment using $(shell
> ...)
> syntax, such as:
>
> src/nwc_columbus/sifs/GNUmakefile
> 38:ALLF = $(filter-out ./sifs_stubs.F, $(shell find . -name '*.F'))
>
> (this is just one example there are 300+ spread across the makefiles).
>
> At the same time I see that various makefiles are forcing all variable
> assignments to be exported; for example:
>
> src/peigs/src/c/Makefile.proto:.EXPORT_ALL_VARIABLES:
>
>
> There are also instances of .EXPORT_ALL_VARIABLES in some Makefiles, but
> these
> are probably not a problem because the Makefiles appear to be for BSD make
> (GNUmakefile is used for GNU Make).  So, there appear to be about 5
> makefiles
> that have this setting.
>
> But, when the Makefile.proto above is included in another makefile, that
> sets
> that parameter for every make instance that includes it.
>
> The simplest solution here is to go through and remove all those
> .EXPORT_ALL_VARIABLES: settings.  This is just a very bad idea.  If there
> are
> specific variables that need to be exported then those, and only those,
> should
> be exported.
>
> Unfortunately there is not any simple solution right now, except either fix
> the makefiles or else limit your version of GNU Make to 4.3 or earlier
> before
> this change was made.
>
> I have been thinking about how to mitigate this issue and I just don't have
> any good ideas.  There doesn't seem to be any good heuristic we can use to
> avoid the behavior without also introducing bizarre and unexplainable edge
> cases.
>
>
> ___
>
> Reply to this item at:
>
>   
>
> ___
> Message sent via Savannah
> https://savannah.gnu.org/
>
>
>

suggestion regarding names of temp files

[DSB]

Minor suggestion: In 9.7 Temporary Files the manual says "These files must
not be disturbed while make is running" but it doesn't say what "these
files" look like. Assuming the names have some pattern, would it make sense
to be more specific and say something like "do not remove temp files
matching gnumake.*"?

confusing language in manual re GNUMAKEFLAGS

[DSB]

I think this little nit should be cleared up. In one place the manual says:

... after parsing GNUMAKEFLAGS GNU make sets this variable to the empty
string ...

But in another place it says:

GNU make never sets this variable itself.

The meaning is clear (to me) but the language is not well formed.