The build of the lexer dub subpackage requires running and building
a little config.d tool as custom pregenerate command.
Forwarding the target architecture via `--arch=$DUB_ARCH` to the
nested dub build of config.d was added in #9275, to fix cross-
compilation, but in reality broke it.
Not specifying the architecture explicitly for the little helper
build lets the compiler pick the default one, the host's native
platform in practice, which is guaranteed to be runnable on that
compiling **host**, independent from the **target** platform for
the main dub build. Suppose one cross-compiles the dmd:lexer
subpackage from x86_64 to AArch64 - an AArch64 config.d executable
will hardly run on the x86_64 host, and won't be able to generate
the `VERSION` and `SYSCONFDIR.imp` string-import files as pre-
requisite of the build.
Side note: using little separately-built .d tools/scripts as build
helpers for autogenerating little VERSION files etc. is IMO bad
practice - when cross-compiling, you require a D compiler that can
a) cross-compile, and b) build successfully for the native platform
too. Not sure this approach will e.g. ever work with GDC, where you
have different toolchains for each host->target combination.
These import backend modules, and that leads to undefined symbol
regressions (backend TypeInfos referencing undefined backend init
symbols) with LDC on Windows for current master (stable is fine).
See https://github.com/ldc-developers/ldc/issues/3212.
This will allow to use the compiler as a library to implement more
unit test like tests. These tests will be able to inspect the
internals of the compiler to perform new kinds of tests that are not
possible today.
Unit tests live in the `test/unit` directory. They are written using
the built-in `unittest` blocks. The unit test framework supports
callbacks executed before and after each test. The unit test runner
allows to limit the tests executed either by file(s) and/or by UDAs.
Example:
```d
module self_test;
import support : afterEach, beforeEach;
@beforeEach initializeFrontend()
{
import dmd.frontend : initDMD;
initDMD();
}
@afterEach deinitializeFrontend()
{
import dmd.frontend : deinitializeDMD;
deinitializeDMD();
}
@("self test")
unittest
{
import std.algorithm : each;
import dmd.frontend;
findImportPaths.each!addImport;
auto t = parseModule("test.d", q{
int a = 3;
});
assert(!t.diagnostics.hasErrors);
assert(!t.diagnostics.hasWarnings);
}
```
* To run all unit tests, run: `./run.d -u`
* To run only the unit tests in a single file, run: `./run.d -u unit/self_test.d`
* To run only the unit tests matching a UDA, run: `./run.d -u --filter "self test"`
The Dub package was unconditionally running the `config.sh` shell
script to generate the `VERSION` file. A Bash shell script will not
work on Windows. Therefore the `config.sh` script has been ported to
D, which will work on both Windows and Posix.
Building the Dub package on Windows results in the following
duplicated symbols: `?backend_init@@YAXXZ` and `?backend_term@@YAXXZ`.
This is solved by excluding the `dmsc.d` file from the Dub package.
The `backend_init` and `backend_term` symbols are both defined in
`gluelayer.d` (when the `NoBackend` version is defined) and `dmsc.d`.
sed -i "s/ddmd/dmd/g" -i **/*.sdl
sed -i "s/ddmd/dmd/g" -i **/*.mak
sed -i "s/ddmd/dmd/g" -i **/*.visualdproj
sed -i "s/ddmd/dmd/g" -i **/*.vcxproj
sed -i "s/ddmd/dmd/g" -i **/*.filters
sed -i "s/ddmd/dmd/g" -i CODEOWNERS
