On Thu, 2025-07-03 at 14:38 +0200, wrotycz wrote:
> > It's not expected that users look at the value of MAKEFLAGS that
> > make itself sets (so, the version generated in a recipe). That
> > format, although documented, is technically internal to make
>
> I was refering to C. Funk's proposition to
> I'm not sure what "documentation, not manual" refers to.
Maybe you mean the man page? Yes. ~~~ $ man man General
Commands Manual man - format and display the on-line manual pages ~~~
According to this man pages are manuals. > It's not expected that
users lo
On Wed, 2025-07-02 at 00:03 +0200, wrotycz wrote:
> Tried to get what the `MAKEFLAGS' is but documentation, not manual is
> not very helpful.
I'm not sure what "documentation, not manual" refers to. Maybe you
mean the man page? The man page is not intended to describe everything
about makefiles
See the last 5 paragraphs, starting with: The MAKEFLAGS variable can also be
useful if you want to have certain options, such as ‘-k’ (see Summary of
Options), set each time you run make.Tried to get what the `MAKEFLAGS'
is but documentation, not manual is not very helpful. Info is bette
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
On Fri, 2025-06-27 at 10:18 -0700, Collin Funk wrote:
> 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'
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
On Fri, 2025-06-27 at 18:41 +0200, wrotycz wrote:
> > 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.
>
> What is MAKEFLAGS? As f
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. What is
MAKEFLAGS? As far as I understand it is command line in form of environmental
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 num
I don't see any need to be aggressive in your response. You're right,
it came out clumsily. I can get -j almost 2x the number of CPU threads
before builds start slowing down, Maybe that 2*nproc is not that bad
estimate, if it comes out I experiments. (b) there's a lot of latency of
> Emotive terminology like "ludicrous" doesn't encourage a
constructive response. You're right. I don't feel in English so it
may be too strong or even not to the point. >> Here is [a] slightly
improved test script[.]>... yet I didn't see one. Script is here:
lists.gnu.org https://li
On Thu, 2025-06-26 at 19:21 +0200, wrotycz wrote:
> > > There are plenty of scenarios where using more jobs than
> > > processor threads results in faster builds: it all depends
>
> You say that because you have tested it or because you believe it?
> I have tested it, But let's bust this ludicrous
> But let's bust this ludicrous idea and show us a test that disproves me
Emotive terminology like "ludicrous" doesn't encourage a constructive response.
If I understand correctly, I think you're describing your own proposal with
that term, as a rhetorical device. It wasn't ludicrous and Paul
Mentioned script.
#!/bin/sh
#URL=http://ftp.gnu.org/gnu/make/make-4.4.1.tar.gz # 34 .o files
#URL=https://mirrors.dotsrc.org/gnu/make/make-4.4.1.tar.gz
URL=https://mirrors.dotsrc.org/gnu/bash/bash-5.2.tar.gz # 193
#URL=https://mirrors.dotsrc.org/gnu/coreutils/coreutils-9.5.tar.gz # ~1859 .c
#URL=h
> There are plenty of scenarios where using more jobs than processor threads
results in faster builds: it all depends You say that because you have tested
it or because you believe it? I have tested it, But let's bust this
ludicrous idea and show us a test that disproves me. Here is slightly
On Wed, 2025-06-25 at 13:34 +0200, wrotycz wrote:
> At the moment, though this moment lasts for decades now, -j/--jobs
> without argument starts infinite number of parallel jobs.
> Practice shows that compilation with jobs bigger than number of
> available threads is not faster in any way, only use
17 matches
Mail list logo
