On Thu, 2017-09-28 at 20:41 +1000, NeilBrown wrote:
> I dug into this a bit.
> The regression is caused because the 'j' flag now causes
> arg_job_slots to be set, rather than setting job_slots directly.
I pushed a fix for this.
___
Bug-make mailing list
Update of bug #48274 (project make):
Status:None => Fixed
Assigned to:None => psmith
Open/Closed:Open => Closed
Fixed Release:
On 30/10/17 21:22, Paul Smith wrote:
If we see -j in a makefile setting of MAKEFLAGS, we could:
1. Always silently ignore it (today's behavior).
2. Always print a message then ignore it.
3. Treat it the same way as a recipe with $(MAKE) -j: that is, start a
new jobserver grou
On Tue, 2017-10-31 at 07:39 +1100, NeilBrown wrote:
> On Mon, Oct 30 2017, Tim Murphy wrote:
>
> > For my money -j is always a top-level setting. To have it per makefile
> > and then let makefiles depend on that behaviour would open the door to lots
> > of scary bugs.
I don't see what scary bug
On Mon, Oct 30 2017, Tim Murphy wrote:
> For my money -j is always a top-level setting. To have it per makefile
> and then let makefiles depend on that behaviour would open the door to lots
> of scary bugs.
I'm beginning to agree with this perspective.
The "-j" setting is not really a function
On 30/10/17 07:33, Tim Murphy wrote:
For my money -j is always a top-level setting. To have it per
makefile and then let makefiles depend on that behaviour would open
the door to lots of scary bugs.
Regards,
Tim
Agreed. Using -j in a Makefile is not portable, because it can cause a
sys
For my money -j is always a top-level setting. To have it per makefile
and then let makefiles depend on that behaviour would open the door to lots
of scary bugs.
Regards,
Tim
On 29 October 2017 at 18:57, Paul Smith wrote:
> On Thu, 2017-09-28 at 16:28 +1000, NeilBrown wrote:
> > One of my Ma
