Use .NOTPARALLEL in posix.mak instead of lockfiles in build.d

[MoonlightSentinel]

They achieve the same behaviour as posix.mak simply forwards to build.d.

This is a workaround for https://issues.dlang.org/show_bug.cgi?id=20999
which seems to be caused by some local library based on these observations:

• the failure is restricted to the macair host, no failures
  on D-Autotester.local
• the failure happens upon the second invocation of build.d
• removing --called-from-make makes the errror disappear.
  This switch enables a lockfile (generated/build.lock) which ensures
  that mutliple instances of build.d are run mutually exclusive (this
  was required during the make -> build.d transition but is obsolete now)

[MoonlightSentinel]

A few observations:

1. the failure is restricted to the macair host, no failures on D-Autotester.local
2. the failure happens upon the second invocation of build.d
3. Removing --called-from-make makes the errror disappear. This switch enables a lockfile (generated/build.lock) which ensures that mutliple instances of build.d are run mutually exclusive (required during the make -> build.d transition).

Maybe it's an issue within the local C library used by std.stdio.File?

[MoonlightSentinel]

[Not ready for review, just curious if Azure doesn't pick up Draft PRs]

[dlang-bot]

Thanks for your pull request and interest in making D better, @MoonlightSentinel! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#11515"

[wilzbach]

Just commenting based on your commits:

• there's no gdb on OSX (by default) as LLVM is the default
• does the error vanish when -lowmem is removed?

[MoonlightSentinel]

• there's no gdb on OSX (by default) as LLVM is the default

Sorry, should've clarified that I hijacked this PR to check for the segfault when building d_do_test which I can't reproduce locally. OSX is currently irrelevant because the segfault only happens on Linux & FreeBSD.

• does the error vanish when -lowmem is removed?

Maybe, didn't test that yet.

[MoonlightSentinel]

Not sure why the auto-tester refuses to test this PR ...

[wilzbach]

Not sure why the auto-tester refuses to test this PR ...

Typically there are either many other recently opened PRs or PRs with "auto-merge" which can't be merged due to other failures.
The preference logic of the auto-tester is roughly:

1. tests new commits to master/stable
2. auto-merge queue
3. normal PRs by commit timestamp

Typically it's a PR being stuck in the auto-merge queue.

[MoonlightSentinel]

Now using .NOTPARALLEL to avoid lockfiles. This still ensures mutually exlusive invocations of build.d unless someone manually start multiple instances of make at the same time (which should be hazardous for every Makefile)

[Geod24]

On a related note, having the parallelization of the test-suite fixed on OSX would be great. Also, this needs a rebase.

[MoonlightSentinel]

Rebased.