Difference between revisions of "DMD development"

From D Wiki
Jump to: navigation, search
m (Update paths to dmd/compiler/)
 
(3 intermediate revisions by 2 users not shown)
Line 6: Line 6:
 
== Tests ==
 
== Tests ==
  
The testsuite is in `~/dlang/dmd/test`. Please go to this directory.
+
The testsuite is in <code>~/dlang/dmd/compiler/test</code>. Please go to this directory.
  
 
<syntaxhighlight lang=bash>
 
<syntaxhighlight lang=bash>
cd ~/dlang/dmd/test
+
cd ~/dlang/dmd/compiler/test
 
</syntaxhighlight>
 
</syntaxhighlight>
  
 
The testsuite will always print the exact command used to run a test, s.t. it's easy to single out and reproduce a failure.
 
The testsuite will always print the exact command used to run a test, s.t. it's easy to single out and reproduce a failure.
  
=== Running the testsuite on Windows ===
+
=== Running all tests ===
 +
 
 +
<syntaxhighlight lang=bash>
 +
./run.d
 +
</syntaxhighlight>
 +
 
 +
The testsuite runner will automatically use all available threads. You can use e.g. <code>-j1</code> to e.g. use one thread.
 +
 
 +
=== Run a specific test category ===
 +
 
 +
<syntaxhighlight lang=bash>
 +
./run.d fail_compilation
 +
</syntaxhighlight>
 +
 
 +
=== Run a specific test ===
 +
 
 +
<syntaxhighlight lang=bash>
 +
./run.d fail_compilation/ice12673.d
 +
</syntaxhighlight>
 +
 
 +
=== Run a set of specific tests ===
 +
 
 +
<syntaxhighlight lang=bash>
 +
./run.d fail_compilation/ice*
 +
</syntaxhighlight>
 +
 
 +
=== Automatically update the OUTPUT text ===
 +
 
 +
<syntaxhighlight lang=bash>
 +
./run.d fail_compilation AUTO_UPDATE=1
 +
</syntaxhighlight>
 +
 
 +
A second run might be required.
 +
 
 +
=== Remove test states ===
 +
 
 +
<syntaxhighlight lang=bash>
 +
./run.d clean
 +
</syntaxhighlight>
 +
 
 +
=== Run unittests within the compiler ===
 +
 
 +
There are a few [[Unittest|unittest]] blocks within the compiler and there usage is increasing.
 +
They can be tested with:
 +
 
 +
<syntaxhighlight lang=bash>
 +
cd ~/dlang/dmd/compiler/src
 +
make -f posix.mak unittest
 +
</syntaxhighlight>
 +
 
 +
 
 +
== Old Makefile targets ==
 +
 
 +
The following section explains the Makefile rules of the <code>test/Makefile</code>. It has been replaced by <code>test/run.d</code> and is only listed here for users who experience problems during the transition to <pre>run.d</pre>
 +
 
 +
== DMD Test Suite - Windows Requirements ==
 +
 
 +
==== Linux Core Utilities (bash/grep/diff/etc.) ====
 +
 
 +
If you have git installed (https://gitforwindows.org) you probably already have the linux core utilities available.  Simply add them to your <code>PATH</code> with:
 +
 
 +
<syntaxhighlight lang=dos>
 +
set PATH=C:\Program Files\Git\bin;C:\Program Files\Git\usr\bin;%PATH%
 +
</syntaxhighlight>
 +
 
 +
Alternatively, you can have digger automatically install them for you (https://github.com/CyberShadow/Digger) or follow these instructions: https://github.com/golang/go/wiki/WindowsBuild#install-mingwmsys
 +
 
 +
==== GNU make (different than DigitalMars make) ====
 +
 
 +
Option 1: use <code>mingw32-make.exe</code> from a MinGW binary
 +
 
 +
Option 2: download binaries from sourceforce
 +
  * You can download a prebuilt binary and its dependencies from here: http://gnuwin32.sourceforge.net/packages/make.htm
 +
  * Download the "Binaries" Zip package and the "Dependencies" Zip package.
 +
  * Extract them and copy "libiconv2.dll" and "libintl3.dll" to the "bin" directory in the unzipped "Binaries" archive.
 +
  * Add the bin directory of the unzipped "Binaries" archive to your <code>PATH</code>
 +
 
 +
Option 3: try the pre-built binaries from this PR: https://github.com/dlang/installer/pull/311
 +
 
 +
'''Important:''' you need to use GNU <code>make</code> to run the <code>Makefile</code> in <code>test</code> - not the DigitalMars <code>make</code> that is bundled with D's Windows binaries.  Run `which make` to see which one is being used.  If it's the DigitalMars' <code>make</code>, you'll need to change the directory order in your <code>PATH</code> by placing the path to GNU's make first.
 +
DigitalMars make is only required for <code>win32.mak</code> and <code>win64.mak</code>.
  
If you run the testsuite on Windows, make sure you install
 
  
- Bash environment (e.g. [https://git-scm.com/download/win Git for Windows] or [https://github.com/golang/go/wiki/WindowsBuild#install-mingwmsys MYS])
 
- GNUMake (a bit harder to find, see the built binaries of [https://github.com/dlang/installer/pull/311 this PR] or use <pre>mingw32-make.exe</pre> from a MinGW binary)
 
  
[https://github.com/CyberShadow/Digger Digger] can install this automatically for you.
 
 
If you are looking for an automated way to turn a VirtualBox in a Development Machine, follow [https://gist.github.com/MartinNowak/8270666 these instructions] to create a ssh-accessible Windows box.
 
If you are looking for an automated way to turn a VirtualBox in a Development Machine, follow [https://gist.github.com/MartinNowak/8270666 these instructions] to create a ssh-accessible Windows box.
  
Line 41: Line 117:
  
 
The test suite stores the results of run tests to allow re-running only the failed tests.
 
The test suite stores the results of run tests to allow re-running only the failed tests.
This state is stored in `~/dlang/dmd/test/test_results` and can be removed with:
+
This state is stored in `~/dlang/dmd/compiler/test/test_results` and can be removed with:
  
 
<syntaxhighlight lang=bash>
 
<syntaxhighlight lang=bash>
Line 88: Line 164:
 
</syntaxhighlight>
 
</syntaxhighlight>
  
=== Run unittests within the compiler ===
 
 
There are a few [[Unittest|unittest]] blocks within the compiler and there usage is increasing.
 
They can be tested with:
 
 
<syntaxhighlight lang=bash>
 
cd ~/dlang/dmd/src
 
make -f posix.mak unittest
 
</syntaxhighlight>
 
  
  
 
[[Category:Contribution Guidelines]]
 
[[Category:Contribution Guidelines]]

Latest revision as of 21:29, 6 November 2022

Welcome to the D community and thanks for your interest in contributing! If you need help you can ask questions on #d IRC channel on freenode.org (web interface) or on our forum.

This section explains commonly commands which are commonly used to test the dmd D Programming Language compiler.

Tests

The testsuite is in ~/dlang/dmd/compiler/test. Please go to this directory.

cd ~/dlang/dmd/compiler/test

The testsuite will always print the exact command used to run a test, s.t. it's easy to single out and reproduce a failure.

Running all tests

./run.d

The testsuite runner will automatically use all available threads. You can use e.g. -j1 to e.g. use one thread.

Run a specific test category

./run.d fail_compilation

Run a specific test

./run.d fail_compilation/ice12673.d

Run a set of specific tests

./run.d fail_compilation/ice*

Automatically update the OUTPUT text

./run.d fail_compilation AUTO_UPDATE=1

A second run might be required.

Remove test states

./run.d clean

Run unittests within the compiler

There are a few unittest blocks within the compiler and there usage is increasing. They can be tested with:

cd ~/dlang/dmd/compiler/src
make -f posix.mak unittest


Old Makefile targets

The following section explains the Makefile rules of the test/Makefile. It has been replaced by test/run.d and is only listed here for users who experience problems during the transition to

run.d

DMD Test Suite - Windows Requirements

Linux Core Utilities (bash/grep/diff/etc.)

If you have git installed (https://gitforwindows.org) you probably already have the linux core utilities available. Simply add them to your PATH with:

set PATH=C:\Program Files\Git\bin;C:\Program Files\Git\usr\bin;%PATH%

Alternatively, you can have digger automatically install them for you (https://github.com/CyberShadow/Digger) or follow these instructions: https://github.com/golang/go/wiki/WindowsBuild#install-mingwmsys

GNU make (different than DigitalMars make)

Option 1: use mingw32-make.exe from a MinGW binary

Option 2: download binaries from sourceforce

 * You can download a prebuilt binary and its dependencies from here: http://gnuwin32.sourceforge.net/packages/make.htm
 * Download the "Binaries" Zip package and the "Dependencies" Zip package.
 * Extract them and copy "libiconv2.dll" and "libintl3.dll" to the "bin" directory in the unzipped "Binaries" archive.
 * Add the bin directory of the unzipped "Binaries" archive to your PATH

Option 3: try the pre-built binaries from this PR: https://github.com/dlang/installer/pull/311

Important: you need to use GNU make to run the Makefile in test - not the DigitalMars make that is bundled with D's Windows binaries. Run `which make` to see which one is being used. If it's the DigitalMars' make, you'll need to change the directory order in your PATH by placing the path to GNU's make first. DigitalMars make is only required for win32.mak and win64.mak.


If you are looking for an automated way to turn a VirtualBox in a Development Machine, follow these instructions to create a ssh-accessible Windows box.

Run all tests which haven't been run before

make all -j8

If you you now rerun this command, the testsuite won't execute anything:

make all -j8

However, if you modified the compiler, it will only rerun the failing tests as these don't have an output stored.

Remove test states

The test suite stores the results of run tests to allow re-running only the failed tests. This state is stored in `~/dlang/dmd/compiler/test/test_results` and can be removed with:

make clean

Always run all tests

make run_tests -j8

Run an individual test

Sometimes it can be helpful to rerun only a single test which tests the fix or feature one is working on:

make test_results/compilable/test10066.d.out

If you want to force re-evaluation of a single test, simply remove the respective file:

rm test_results/compilable/test10066.d.out
make test_results/compilable/test10066.d.out

Run quick test

Often one makes a small change and wants to quickly know whether this change completely broke the compiler. For this, the target make quick exists:

make quick

Run group of tests

Sometimes it can be useful to run only a subset of tests. The testsuite groups the test in three groups: runnable, compilable and failed_compilation. They can be run individually:

make run_runnable_tests:         # run just the runnable tests
make run_compilable_tests:       # run just the compilable tests
make run_fail_compilation_tests  # run just the fail compilation tests