Add variable BUILD_JOBS to posix.mak, which allows to set the number of
jobs for build.d. This will be used by a separate pull request for
dlang.org to manually set it, because the automatically calculated
number of CPU cores is too high.
To finally have DMD's own assertions properly CI-tested. Assertions have
so far only been enabled for CircleCI (reduced testsuite on Linux x64)
and one Azure job (Win64 debug).
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)
Implements C++ ABI tags with a few more restriction than the previous PR (9995).
In particular, do not follow C++ source-level conventions when impractical
(e.g. propagation). Since this is a feature that will be seldom used by users,
I favored implementation simplicity over user-friendly semantics.
Co-Authored-By: سليمان السهمي (Suleyman Sahmi) <sahmi.soulaimane@gmail.com>
OSX 32 bits builds and tests were disabled on the auto-tester but `make install` was still being run and sometimes hangs to at most an hour for obscure reasons.
- Allow them to be directly executable (via the DMD DUB package)
- Add a wild rule to avoid redundant logic
- Remove irrelevant link flags like `-L-lstd++`
- Move example binaries to the generated directory
- Start building the examples on auto-tester (Posix-only for now)
- Make Phobos path in impvisitor example more robust
- we don't have any invariants in dmd, but pay quite some
overhead for the redundant checks
- even though dmd's backend is not that good and fairly slow
at optimizing, the cost amortizes over the whole test suite
(~25% speed-up for me)
- actually test what we ship ✓
- at best we'd run a release build w/ assertions, but dmd
doesn't currently support this (required sth. like -release=assert)
