help-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A solution to achieve partial .NOTPARALLEL


From: David Boyce
Subject: Re: A solution to achieve partial .NOTPARALLEL
Date: Fri, 31 Jul 2020 07:56:47 -0700

I haven't looked closely at your example but the problem reminds me of one
for which I have a different solution. See attached Makefile and run "make
help" to get started. My solution assumes Linux or at least the presence of
an equivalent command-line interface to file locking.

David B

On Fri, Jul 31, 2020 at 6:35 AM David Deutsch <skore@valanx.org> wrote:

> 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
>
>
>

Attachment: Makefile
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]