Re: About .NOTPARALLEL

[Lane Schwartz]

On Sun, Apr 17, 2011 at 8:06 PM, Paul Smith <address@hidden> wrote:

> On Sun, 2011-04-17 at 16:44 -0500, Peng Yu wrote:
> > However, I think the syntax of .NOTPARALLEL can be improved a little.
> > For example, I'd like the a.txt and b.txt are not generated in
> > parallel with anything other .txt files, but c.txt and d.txt be
> > generated in parallel, when '-j' option is used. Currently the
> > following Makefile is essentially the same as the above one. May I
> > suggest to add this syntax to make?
> > .PHONY: all clean
> >
> > all: a.txt b.txt c.txt d.txt
> >
> > .NOTPARALLEL: a.txt b.txt
> >
> > %.txt:
> >       sleep 2; touch $@
> >
> > clean:
> >       $(RM) *.txt
>
> There are two issues here.  First, deciding on the syntax is one thing;
> implementing it inside of GNU make is decidedly another thing entirely.
> Currently make has a concept of parallelism, or no parallelism.  There's
> no concept of "per-target parallelism".  Getting make's internal
> algorithms to understand that some targets should not be built in
> parallel, skipped, and come back to later when there's nothing else
> running is not a trivial change.
>
Paul,

I understand that implementing this change would be non-trivial. That said,
I'd like to voice my support for this feature request.

Just this week I found myself wanting this functionality. Most of the jobs
launched by my make file can be run in parallel, but a non-trivial subset of
them can't be.

Eli's suggestion of using --load-average with -j is a good solution if the
reason for specifying some jobs as nonparallel is to prevent overloading the
CPU. But there are other use cases where that solution isn't the answer. In
my case, there are issues related to the specific programs being launched
that cause error conditions when certain jobs are run in parallel. My
current workaround is to run make twice, building some targets (the ones
that support parallel execution) first with -j, then run make again without
-j to finish building the rest of the targets.

Paul, your suggestion of using order-only dependencies is a good one, and it
may solve my problem is some cases. But it would be pretty awkward to use in
my current situation.

That's my 2 cents, anyway. I can certainly live without Peng's
proposed feature enhancement, but it sure would be nice to have.

Cheers,
Lane