A solution to achieve partial .NOTPARALLEL

[David Deutsch]

Hey everybody,

I've been looking through the mailing list trying to come up with an
answer to how I could do .NOT_PARALLEL for some targets but not others.

There hasn't been a solution thus far and it has been mentioned that
implementing it in make itself might be highly non-trivial. I think that
I've come up with a solution for my case that I wanted to share with
you. Perhaps it could inform a more generalized solution.

So in my case, I want to create linux user accounts as a target like so:


/home/[newUserName]/:
    adduser [newUserName]


If you run this in parallel with other targets like it (just replacing
[newUserName], of course), it fails because you get user ID conflicts
(it tries to use the same user ID for all of the accounts, because they
all iterate on the same base number, which creates a lot of issues)


My solution looks like this:


ifeq ($(origin NOTPARALLEL),undefined)
NOTPARALLEL :=
endif

/home/[newUserName]/: | $(NOTPARALLEL)
    adduser [newUserName]

NOTPARALLEL += /home/[newUserName]/


so that no matter how many times or where I use this snippet, all of the
targets are lined up sequentially.


This got me wondering though: Perhaps this kind of "grouped
non-parallel" approach could actually work out and be cheap to implement?

As in - If you write:

.NOTPARALLEL: target_a target_b target_c

target_a:
    myCmd

target_b:
    myCmd

target_c:
    myCmd


That gets interpreted as:

ifeq ($(origin NOTPARALLEL),undefined)
NOTPARALLEL :=
endif

target_a: | $(NOTPARALLEL)
    myCmd

NOTPARALLEL += target_a

target_b: | $(NOTPARALLEL)
    myCmd

NOTPARALLEL += target_b

target_c: | $(NOTPARALLEL)
    myCmd

NOTPARALLEL += target_c


I know that it's not a perfect solution (and it would be hard to make
this work with pattern rules), but perhaps it's good enough to at least
cover most of the cases where people expect ".NOTPARALLEL: x y z" to
work this way?

The other caveat of this is that an order-only-prerequisite only means
that this would work for newly generated files, not for updating them.
For that you'd need regular prerequisites, but then you'd interfere with
recipes that depend on a clean $^ variable.


best regards,
David