Building and Testing - bobjervis/parasol GitHub Wiki

General Notes

An Eclipse project is defined that does the actual recompilation of the C++ code. The .project file that is checked into the repo is for Eclipse Kepler for Windows or Neon on Linux. Other versions of Eclipse probably will work.

Linux Development

Building the parasolrt Runtime Host

Currently, the C++ code of the Parasol runtime host is built using a makefile generated from the the Eclipse IDE. You do not need to use Eclipse to take advantage of the makefile, but you will have to have the GNU C++ compiler and runtime libraries installed.

There are two Eclipse projects defined in the Parasol repository. The project in the main directory should be loaded for Windows development, while the project in the z_linux directory should be loaded for Linux development.

Setup

You can run the makefile or use Eclipse to build the parasolrt binary without additional steps. However, the easiest way to run the built binary without copying it somewhere else is to run the following script in the z_linux directory. It will set up some links so that the Linux build directory looks like a complete Parasol runtime installation:

z_linux/setup

The Eclipse project is set up so that you should not submit any of the .o files, but take care to avoid submitting .o files to the repository.

SectionType enums

This enum is actually defined in the Parasol sources. The corresponding C++ header file (parasol_enums.h) is built from the Parasol sources using the following command:

genhdr compiler/main.p runtime/Parasol/parasol_enums.h

This genhdr script will parse the compiler sources, extract declarations marked with the @Header annotation and writes them using C++ syntax. Each enum member is written with a prefix given in the @Header annotation. For example, in src/lib/pxi.p, the SectionType declaration looks like:

@Header("ST_")
enum SectionType {

If you omit the argument entirely, each enum member will have the prefix "" attached. This is a bug. The @Header annotation with no argument should be equivalent to @Header("").

Currently, you cannot annotate a class declaration with a @Header annotation. The intention is to extend this in the future, in particular to facilitate the implementation of exception handling (since at least some exception handling code has to be written in C++).

Building the x86_64_lnx.pxi Runtime

The script rebuild will build a new pxi file and test it. Try to avoid checking in changes while this script fails.

The process starts by building a series of pxi files, each built using the prior one. ormally that process will converge on identical pxi files after two iterations, but recently a set of metadata changes only converged after three iterations.

The rebuild process involves running the full test suite using the newly built binaries. This suite takes around 15-20 minutes, is currently single-threaded, and consumes around 250MB of RAM.

Testing

The script regress will run the full suite of tests based on the current state of the compiler/runtime sources. This script will run over 2,000 tests and verify that the compiler successfully builds itself. It takes about 15-20 minutes to complete.

If one of the 'run' tests fails, or indeed any of the test files found in test/src, you can run them individually by using the unit script, with the base name of the source file. For example, if you wanted to run the script test/src/coerce_ops.p, you would use the command line:

unit coerce_ops

Most of these individual tests run almost instantly and none take more than a couple of seconds to complete.

Windows Development

Requirements

You will need the mingw-w64 GNU C++ build toolset. The current Parasol product is built with mingw version 3.0.0. The mingw project has much newer versions, which will probably work but your mileage may vary. Please report any issues and I will work to get the builds updated.

Building The Parasol.exe Runtime Host

Currently, the C++ code of the Parasol runtime host is built using the Eclipse C++ build process, integrated with mingw-64. This generates the file debug\Parasol.exe as well as some .o files in a few sub-directories under debug. You can delete the directories containing .o files at any time. The Eclipse project is set up so that you should not submit any of the .o files, but take care to avoid submitting .o files to the repository.

SectionType enums

This enum is actually defined in the Parasol sources. The corresponding C++ header file (parasol_enums.h) is built from the Parasol sources using the following command:

bin\pc src/util/genHeader.p compiler/main.p runtime/Parasol/parasol_enums.h

This genHeader.p script will parse the compiler sources, extract declarations marked with the @Header annotation and writes them using C++ syntax. Each enum member is written with a prefix given in the @Header annotation. For example, in src/lib/pxi.p, the SectionType declaration looks like:

@Header("ST_")
enum SectionType {

If you omit the argument entirely, each enum member will have the prefix "" attached. This is a bug. The @Header annotation with no argument should be equivalent to @Header("").

Currently, you cannot annotate a class declaration with a @Header annotation. The intention is to extend this in the future, in particular to facilitate the implementation of exception handling (since at least some exception handling code has to be written in C++).

Building the x86_64_win.pxi Runtime

The script bin\rebuild will build a new pxi file and test it. Try to avoid checking in changes while this script fails.

The rebuild process involves running the full test suite using the newly built binaries. This suite takes around 10 minutes, is currently single-threaded, and consumes around 250MB of RAM.

Testing

The script bin\regress will run the full suite of tests based on the current state of the compiler/runtime sources. This script will run over 2,000 tests and verify that the compiler successfully builds itself. It takes about 15-20 minutes to complete.

If one of the 'run' tests fails, or indeed any of the test files found in test\src, you can run them individually by using the bin\unit script, with the base name of the source file. For example, if you wanted to run the script test/src/coerce_ops.p, you would use the command line:

bin\unit coerce_ops

Most of these individual tests run almost instantly and none take more than a couple of seconds to complete.

⚠️ **GitHub.com Fallback** ⚠️