mps-tips

build-language

The MPS build-language can be used to describe an ant build script for building your languages and solutions from the command line. The solution containing your build script is usually called the build-solution. There is also a section about the build-language in the official MPS docs

This page was written for and with MPS 2022.2

General

• If you are building an MPS plugin (like a language), you should usually also include the build-solution as part of the content of that plugin
• Whenever you change the dependencies of any of the solutions or languages you are building you have to Reload Modules from Disk (Intention) of that solution/model
  • This is also the case for the build-solution
• Usually you want your plugin to depend on jetbrains.mps.build instead of the jetbrains.mps.core the wizard generates

How to add a dependency to the build process

1. The project you depend on MUST have a build solution
2. Open the model properties of the model, in which your build script is located
   • Add the build solution of the dependency to the Dependencies of that model
3. Add the dependency to the dependencies section of your build script

     dependencies:
    mps (artifacts location $mps_home)
    name.of.the.dependency (artifacts location <no artifacts>)
   

4. Set the artifacts location of the dependency. This should be the folder containing all the mps plugins. I’d suggest using a folder macro for this.
5. Add the dependency to the dependencies section of your plugin plugin

Choosing a default layout that allows your plugin to be depended on in other build scripts

With the default build script generated by the wizard, I have encountered a problem. If in the build script of another project depend on the plugin built using that build script, the location generated in the ant script is <plugin path="${build.tmp}/deps/name.of.the.dependency/name.of.the.dependency.zip/name.of.the.dependency" /> instead of the expected <plugin path="${artifacts.name.of.the.dependency}/name.of.the.dependency" />. This leads to the problem, that the plugin cannot be found by the build script when actually running it from the command line. (Curiously, I’ve found there is no problem when using right-click -> Run on the build script in MPS)

I’ve determined that this is caused by the default layout of the build script. The wizard generates the build script in a way, where the default layout contains a zip containing the plugin. But for the correct path to be generated, the first entry of the default layout must be the plugin itself. It is fine, if there is a zip entry after the plugin entry.

Therefore, I suggest to change the default layout (of the build script of name.of.the.dependency) to the following:

default layout:
  plugin name.of.the.dependency [ auto packaging ]
    # Readonly part ... # end of readonly part
    <empty>

  zip name.of.the.dependency.zip
    plugin name.of.the.dependency [ auto packaging ]
      # Readonly part ... # end of readonly part
      <empty>

Including external JARs

• See also the mps docs and this blog post.
  • But I’ve found the the error No such path in local layout still occured after adding the file to the layout.
    • In my case it turned out, I needed to specify the path to the file exactly as the path to the jar in the dependencies of the solution.
      • This path can be found by invoking the intention Unfold <solution name> on the solution and looking at the dependencies.
      • In my case it was $project_home/solution/some.solution/libs/some.jar instead of ./solution/some.solution/libs/some.jar.
      • It seems to be necessary to specify the exact same path even though $project_home = . in my case.

This site is open source. Improve this page.