Path variables
To avoid complications when moving projects from one computer to another, MPS provides path variables (a path variable is a variable whose value is an absolute path to a directory or file).
Path variables are particularly useful when working with third-party libraries stored outside the project directory.
In brief, using path variables is reasonable under the following set of conditions:
There are third-party libraries in your project defined at the project level.
These libraries are stored outside the project content root.
There is a need to work with the project on more than one computer (for example, share the project among the development team members through version control).
Usecase example
To illustrate, let’s assume there is a project shared among a team of developers (for example, through version control), and there is a library in this project defined at the project level.
Everything goes fine if the library is located under the project content root. A fairly frequent situation is when the library location is external to the projects. Such a library is referenced by its absolute path and there’s no guarantee that this path is the same on every one of the computers used by the team.
The obvious solution is to define a path variable for the library location. In such a case, the library path may be set individually on each of the computers.
In addition to that, such path variables should be reflected in build scripts of your project. To avoid specifying absolute paths in build scripts, the build language offers folder macros. A folder macro should be defined at the beginning of your build script and then used whenever a path to any of the libraries is specified. A Build script wizard when creating a new build script inserts all existing path variables as folder macros automatically for you.
Ignored variables
If when opening a project, MPS detects unresolved path variables, it asks you to define proper values for them. If you don’t want to do that (for example, you are not going to use the corresponding library or libraries), you have an option of adding the corresponding variables to a list of ignored variables.
There may also be other cases when the list of ignored variables is useful.
At the internal level, path variables are represented by strings in which the name of a variable is enclosed between a pair of dollar sign characters, for example, $MY_PATH_VARIABLE$.
Such a pattern, in principle, may occur in your project without the meaning of a path variable.
To tell MPS that a string that starts and ends with a dollar sign character (for example, $SOME_STRING$), actually, is not a path variable, you should add such a string (for example, SOME_STRING) to the list of ignored variables.