Phobos development

From D Wiki
Revision as of 21:01, 11 December 2017 by Greenify (talk | contribs) (Created page with "This page explains commonly used commands that are used while working with the D standard library <tt>phobos</tt>. = Unittest <tt>phobos</tt> = == Full build == If you want...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

This page explains commonly used commands that are used while working with the D standard library phobos.

Unittest phobos

Full build

If you want to work on phobos itself, you need to run unittests—either for the full library, a package, or a module. To unittest the entire library:

make -j16 -f posix.mak unittest

Adjust the parameter passed to -j depending on your machine (beefier machines support larger parameters). This command unittests phobos in both debug and release mode. To only test one of them, add BUILD=debug or BUILD=release to the command line, for example:

make -j16 -f posix.mak BUILD=debug unittest

Specifying BUILD makes unittesting faster so it is recommended in iterative development. Just make sure both debug and release builds are tested before e.g. submitting a pull request.

Test a single Phobos module

While changing one specific package or module, it's useful to be able to only unittest that particular entity. The following two commands only unittest (in debug mode) the std.algorithm package:

make -j16 -f posix.mak BUILD=debug std/algorithm.test

Several modules, packages, or mix thereof may be specified for testing in the same command line. For example, this command also tests (and also in debug mode) the std.algorithm package and the std.conv module, with better parallelism:

make -j16 -f posix.mak BUILD=debug std/algorithm.test std/conv.test

Test a single module without rebuilding Phobos

You can test a module directly with rdmd:

rdmd --compiler=~/dlang/dmd/generated/linux/release/64/dmd -unittest -main std/algorithm/sorting.d

(If you are on a different platform, replace linux> with your respective platform)

However, be aware that this method doesn't recompile the Phobos library and thus only checks the executed file. Thus you should only use this for fast builds on small changes.

Run CI checks

The auto-tester will fail your PR if your changes contain trailing whitespace or incorrect line endings. You can run this test locally with the command:

make -j16 -f posix.mak checkwhitespace

CircleCi will also run various checks for the DStyle and ensures that every example is runnable on dlang.org. You can run this test locally with:

make -f posix.mak style