Editing code of course requires the MPS editor. But generating models and
running tests can be done from the command line to integrate it with automatic
builds. Ant is used as the basis. In this section we explain how to use MPS
from the command line via ant.
For all of the examples we use a build.properties file that defines the
following two properties:
This build.properties file is included in all the build scripts we discuss
in this section. In addition, we have to define a set of MPS-specific tasks
using the taskdef element in ant. Also, a couple of JVM options are reused
over and over. Consequently, the following is a skeleton of all the build files
we will discuss:
We start by building the contents of a project. Here is the necessary ant code
that has to be surrounded by the skeleton ant file shown above:
All modules within the project are generated. If only a subset of the modules in
the project should be generated, a modules fileset can be used. The
following code generates all the languages in a project; typically they reside
in the languages directory below the project. Note how we define a
different property that points to the project directory as opposed to the
project (.mps) file.
Sometimes a project needs access to other languages in order to be compilable.
These can be added with library elements, whose dir attribute has to
point to a directory that (directly, or further below) contains the required
Building solutions that contain code written in a DSL is not fundamentally
different from building languages. However, it is important to set up the
libraries correctly so they point to the directories that contain the languages
used in the solutions.
MPS supports a special testing language that can be used for testing
constraints, type system rules and editor functionality. These tests can be run
from the UI using the Run option from the solution or model context menu
(see the figure below).
These tests can also be run from the command line. Here is the code you need:
The important ingredients here are the two system properties
mps.junit.project and mps.junit.pathmacro.mbeddr.home. The first one
specifies the project that contains the tests. The second one is a bit more
involved. The syntax mps.junit.pathmacro.XXX sets a value for a path
variable XXX in an MPS project. To make the tests run correctly, there has
to be a TestInfo node in the project that points to the project file. This
one uses a path variable (defined in MPS settings) to make it portable between
different machines and various locations in the file system. The
mps.junit.pathmacro.mbeddr.home thingy is used to supply a value for the
macro from the command line.