Compiling Storm from Source

The pre-compiled binaries provided on this page are enough for most tasks. However, if you wish to integrate external libraries into Storm, or change things in the compiler itself, it is necessary to build Storm from source. Building from source is also an option in case the pre-compiled binaries do not work on your system for some reason.

The remainder of this page describes how to compile Storm on Windows and Linux. The end of the document also outlines how to use Mymake to work conveniently with Storm, and how to integrate the entire flow into Emacs.

Installing Dependencies

The first step is to ensure that all dependencies are installed on your system. Storm is written to require fairly few dependencies, and the dependencies it does require (apart from Mymake) are in many cases already installed on your system. In short, Storm requires Mymake (the build system), a C++ compiler, and a few libraries for graphics and sound on Linux.

Windows

The following software is needed on Windows. You may already have some of this software installed. If so, you do not need to install it again, as Storm does not require a particular version of these tools to build. Storm does not require any additional libraries, so it is enough to install Visual Studio and Mymake.

Linux

On Linux, Storm requires Mymake (the build system), a C++ compiler, Git to fetch the source code, and a few libraries to interact with the system. As on Windows, Storm is not very sensitive about the exact versions that are used, so the ones available for your system will likely work. Note, however, that Storm has only been tested with GCC. It should be possible to build it using Clang as well, but this has not been tested.

Downloading the Source Code

The next step is to download the actual source code for Storm. The repository for Storm contains a number of submodules, so it is easiest to use the following command:

git clone --recursive git://storm-lang.org/storm.git

If, at a later time, the submodules become out of sync (for example, if they were updated from upstream), the command git submodule update makes sure the proper version of each submodule is checked out. If a submodule is missing entirely, run git submodule init followed by git submodule update.

As of version 0.16.19 of Storm, cloning the entire repository from scratch downloads around 810 MiB of data and requires around 1.1 GiB of disk space.

Skipping Submodules

If you wish to reduce the amount of data that is downloaded, or wish to reduce the disk space required, you can ignore some of the submodules. If you are on Windows, you can ignore the submodules in the Linux/ directory. Among others, this directory contains the cairo and skia submodule that is around 500 MiB. On Linux, you can likely ignore the cairo submodule, as it is not used by default. To selectively download submodules, it is necessary to clone the repository in two steps. First, clone the Storm repository without the --recursive flag:

git clone git://storm-lang.org/storm.git

Then initialize all submodules. This also provides a list of the submodules so that it is possible to deactivate them later:

cd storm
git submodule init

Then, for each submodule that you don't wish to download, execute the following command. The example below removes both the cairo and the skia submodules:

git config --remove-section submodule.Linux/cairo
git config --remove-section submodule.Linux/skia

(Note: git submodule deinit should work, but does not seem to work properly before cloning the submodule.)

When you are done, run git submodule update --progress to clone the remaining submodules.

Compiling Storm

Once all dependencies are installed and the source code is downloaded, Storm can be compiled using Mymake. To understand how the process works, we need to know a little bit about how Mymake works.

According to Mymake, Storm is a project that consists of a number of targets. The project is the root of the Storm repository (it contains a file called .myproject). Each target is a subdirectory in the project directory. Each target contains a file named .mymake to indicate this. This means that the directories Test and Main are targets, while scripts, doc and root ar not targets.

To compile a project, Mymake needs to know which target it should produce (this can be specified in the project file, but this is not the case for Storm). As such, we can compile different parts of Storm depending on which target we ask Mymake to compile. The two most important targets for Storm are Main and Test. The target Main produces Storm's main executable (distributed as storm), while the target Test compiles the test suite in Storm.

Finally, it is worth knowing that the default behavior of Mymake is to not only compile the selected target, but to also run it if compilation was successful. As such, it is possible to run and compile Storm with the following command:

mm Main

Similarly, the test suite can be compiled and run with:

mm Test

The commands above both produce binary files in the debug/ directory. If you do not want Mymake to execute the created file, the flag -ne disables this behavior.

Compiling Storm from scratch typically takes a couple of minutes on recent hardware. However, if you are building Storm on Linux, it must first compile the Skia library, which can take upwards of 10 minutes, even on recent hardware. This is, however, only done once as Mymake tracks updates to files and only re-compiles the necessary files.

Compilation Options

The build files for Mymake have a few configuration options that modify the behavior of the build. Note that Mymake tracks the command lines used to produce intermediate build files. This means that Mymake produces a correct build when the build options have changed, even without a clean in between. However, it also means that a large portion of Storm need to be rebuilt when options change.

The following options are available:

Common Errors

Mymake utilizes precompiled headers to speed up the build process. This is generally positive, but can cause issues in some cases. In particular, the precompiled header files are closely tied to the exact version of the compiler that is being used. This means that the build process might fail whenever the compiler has been updated. Typically this results in a message that says that a "pch file" or "precompiled header" is invalid. This error is resolved by deleting all files with the extension pch (on Windows) and gch (on Linux). In a Unix-like shell, this can be done as follows:

find . -name "*.gch" -exec rm \{\} \;

Using Mymake to Run Storm

When developing Storm with Mymake, it is often convenient to let Mymake handle both compilation and execution of Storm. This means that it is enough to keep track of a single command line for building and testing the program, rather than keeping track of separate ones.

To test a specific piece of code in Storm, it is necessary to pass parameters to the compiled Storm program. Mymake enables this by passing any parameters specified after the special parameter -- directly to the compiled program. As such, anything that appears after a -- on the Mymake command line will be passed directly to Storm. For example, to pass the parameters -f progvis.main to Storm upon successful compilation, specify the following parameters to Mymake:

mm Main -- -f progvis.main

Other parameters, like -i or names of files, can be specified as usual as well. Note, however, that even though it is possible to execute Mymake in any subdirectory in the Storm repository, Mymake will set the current directory to the root of the repository before doing anything. This means that any relative paths passed to Storm will be incorrect, and errors will be reported. As such, to avoid this kind of surprises, it is a good idea to always run Mymake in the root of the Storm repository.

Note: In versions of Mymake earlier than 2.3.3, the flag -- was not available. In these versions, use -a instead of --.