Options

The model compiler supports a wide range of command-line options to control code generation, building, licensing, validation, and more.

Use these options to customize how your models are compiled and integrated into your build environment. This section provides a reference for each available option.

Option Description
--autoComputeAbstractProperty By default, the model compiler will automatically compute if a class or capsule is abstract, by analyzing its local and inherited operations. If the class or capsule contains at least one pure virtual operation that is not redefined or an interface operation that is not implemented, it will be considered abstract. In older versions of the model compiler it was necessary to manually set the Abstract property to be consistent with the operations. Set this option to false if you prefer that behavior.
--build[=<target>] Build generated code once it has been generated. If this option is not used, the model compiler will only generate C++ code and make files and will not invoke any make tool in order to build the code. This option is typically used when building a model by a single invocation of the model compiler from the command-line. The make command to be used is taken from the TC. By default, the make target "all" will be used, but you can specify a different make target after an equal sign. For example: 
--build=mytarget
--buildConfig="config" Specify a concrete build configuration for the current build. A build configuration is a string holding a semicolon-separated list of exact settings for build variants declared in the build variants file. Each such setting maps to invocations of build variant scripts being invoked during the build. See the documentation about Build Variants for more information. For example: 
--buildConfig="Platform=Linux64;Config=Debug;GNU Cov"
--buildVariants=<file> Specify a JavaScript file that initializes build variants available for builds. See the documentation about Build Variants for more information.
--codeStandard=<arg> By default, the model compiler generates code which requires a C++ 17 compiler, but if you use a compiler supporting a different language standard you can set this option. The following arguments are accepted:
  • c++11 - Generate code which requires a C++ 11 compiler.
  • c++14 - Generate code which requires a C++ 14 compiler.
  • c++17 - Generate code which requires a C++ 17 compiler. This is the default.
  • c++20 - Generate code which requires a C++ 20 compiler.
  • c++23 - Generate code which requires a C++ 23 compiler.
  • pre-c++11 - Generate code for an older C++ standard (before C++ 11).
Note that for this code standard you also need to use an older version of the TargetRTS which doesn't contain any C++ 11 constructs. This option can hence be useful if you want to use the latest version of Model RealTime to develop applications that were originally created with older versions of Model RealTime where a C++ 11 compiler was not used.
--codeCompliance=<arg> Use this option to ensure that the generated code complies with certain rules checked by static code analysis tools. Currently the following arguments can be used (corresponding to supported static code analysis tools): 
clang-tidy
Generated code will be compliant with certain Clang-Tidy checks. Depending on situation the generated code will be made compliant either by being adapted to avoid constructs that static code analysis tools complain about, or by inserting special comments into the code to suppress checks for code constructs that are known to be correct.
--cwd=<path> Sets the current working directory. If you do this you can then use paths relative to that working directory, for example when specifying the TC file, or the root folder.
--env=<file> Specifies an environment file, which is a text file containing variables that control the detailed behavior of the model compiler. Each variable should be specified on a separate line in the file according to the format 
<variable-name>=<variable-value>
It is also possible to use command-line options, environment variables or JVM system properties for specifying values for these variables. For more information and a list of all available variables that can be used see Model compiler variables.
--exportModelMapping=<file> This option generates a file with information about how model elements are mapped to places in generated code. This information is used by Model RealTime when it launches the model compiler to implement various navigation commands. You should not use this option yourself when calling the model compiler.
--exportMsg=<path> Causes the model compiler to generate a file (in the specified folder) containing messages produced during code generation. These messages are also printed to the console, but with less detail. The generated file is primarily used when integrating the model compiler with the Model RealTime user interface, and you will normally not use this option otherwise.
--forceOverwrite By default, the model compiler will not regenerate a file if its contents have not changed from last time it was generated. This ensures that the make tool will not build source files that have not been changed. If you set this option the model compiler will overwrite all files even if their contents have not changed.
--genBuildInfoRules This option can be used to generate additional rules into the make file which will print a file with information about the build. The file is in JavaScript syntax and contains information about, for example, which source elements are built, which compiler that is used, the name of the target binary etc. Note that this option only works for inclusive make files, so ensure that you also specify the --inclusiveBatch option. To generate the information file run this command after running the model compiler command: 
<make> -f batch.mk build_info
A file called TC_build_info.js (where TC is the name of the built TC) will be generated.
--genSource="<elements>" This option can be used to restrict the model compiler to only generate code for a specific set of model elements. You can specify the elements in a few different ways: By the XMI id of the element (prefix the id with '#'), by the fully qualified name of the element (prefix the qualified name with '@'), or by the platform resource URI of the element. Separate the elements with spaces in the argument string. Example: 
--genSource="#_S-PlsGoLEeaMRsIRlk4stQ @MyPkg::MyClass platform:/resource/NewCGTest/HelloWorld.emx#_SHU8AGX EeaTEcy2sB6amw"
(Generate source code for three elements specified by XMI id, fully qualified name, and platform resource URI respectively).
--genUnit=<file> Tells the model compiler to generate the unit header and implementation files for the argument TC file. No other source code files will be generated, unless the ––genSource option is also used.
--generate=<arg> Specifies what type of files should be generated by the model compiler. The following arguments are supported for this option:
  • all - Both make files and source code files are generated (default).
  • makefile - Make files are generated.
  • source - Source code files are generated. A CDT project file is also generated. You can import it into an Eclipse workspace for looking at the generated source code files.
--help Prints all available options with brief descriptions to the console. The model compiler then terminates.
--inclusiveBatch This option corresponds to the model compiler variable RTMakeMode=inclusive (See RTMakeMode option in Model compiler variables section).
--keepBuilding If multiple TC files are passed to the model compiler its default behavior is to build them one by one. If building one of the TCs fails remaining TCs will not be built. Set this option to change this behavior so that all TCs are built regardless if errors occur.

--licenseServer=<serverURL>

--licenseBorrowInterval=<duration>

--licenseKey=
  • Specifies a URL of a locally set-up license server, or a cloud license server.
    An example of license server URL is 
    --licenseServer=https://cloudserver.com/v1/licensepools/XXXXXX/leases
  • Specifies a borrow time for the license, which determines the time during which the license is kept. By default, the borrow time is set to 24 hours (86400 seconds).
    For example: 
    --licenseBorrowInterval=600
  • Specifies a valid license key to activate the product and authorize its use. Please note that you can either use the license key or opt for the license server—activating one will automatically disable the other.
    Specifies where to obtain a license for the model compiler.
    The format of the argument depends on the kind of license you have.
    It is on the form <type>:<key>. The <type> should either be “flex” (floating license) or “key” (authorized user license). The <key> specifies the actual license. For “flex” it should be a license server host address: <port@hostaddress> For “key” it should be the license key string.
    Not all features of the model compiler require a license. If you get a message about a missing license, you need to use the --license option to specify the license to use. In case of a floating license the model compiler keeps the license checked out until it terminates.
--list=<arg> Use this option if you want information printed about what the model compiler will generate. By default, information is printed for all TCs that are built. This information includes for example the type of TC (executable, library etc.), the path to the target folder where generated files will be placed, etc. If you set <arg> to "sources", information will instead be printed about all source model elements that will be transformed. You will see the fully qualified name and kind of each source element.
--optionsfile=<file> Reads model compiler options from a file instead of specifying them on the command-line. This may be useful in case you run into too long command-lines or simply just prefer to edit options in a text editor. The options file should be a text file with each option specified on a separate line according to the format <option-name>=<option-value>. For options that do not take a value, the format is <option-name>= Here is an example: 
root=C:\myworkspace
env=C:\modelcompiler\mcenv.map
out=C:\modelcompiler
build=
If an option is specified both on the command-line and in an options file, then its value on the command-line takes precedence.
--organizeSources This command corresponds to the Organize Sources button on the Main tab of the TC Editor. The model compiler will analyze source dependencies based on model references. For an executable TC the analysis starts from the specified top capsule, while for other TCs it starts from the specified source elements. The result of the analysis is a list of elements that are suggested to be added as new source elements of the TC, and a list of elements that are suggested to be removed from the sources list. The messages are printed on a format so you can directly use text from them to update the "sources" TC property using the Code tab in the TC editor.
--out=<path> Specifies the output folder for the model compiler. The workspace output path that is specified in the TC will be appended to this path to define the location where all generated files will be placed.
--pathmap=<path> Specifies a file with path maps. This option must be used if your model contains pathmap URIs (URIs that start with "pathmap", for example href="pathmap://RT_SAMPLE_LIB/RTSampleCustomLibrary.emx#_FPfjMF83EeiD6r1CftWc8g?RTSampleCustomLibrary/BaseA?"). See Path Maps for more information.
--root=<path>
or
--root=<map file>		 Specifies the root folder for the model compiler. All references in models and TC files will be resolved based on this root folder. It is therefore usually set to the workspace folder: --root=<path to existing workspace>. In this case the model compiler will automatically detect the location of all projects based on workspace metadata (no matter if they are imported into the workspace from other locations or not). The <path> argument can use constructions like "<path to dir>*" or "<path to dir>/*" to enable auto-scan for all sub-folders when resolving platform resource URIs. Note that path must be quoted in this case. It is also possible to specify individual locations of all projects in a map file and provide it as an argument for this option. A map file is a text file where the location of each project is written on a separate line, like this: <project-name>=<path-to-project-folder>. Environment variables and system properties can be used inside the map file using the syntax $(var) or ${var}. The --root option can be specified multiple times. All values are merged. The last value provided overrides previous ones.
--rteSharedLoc=<path> This option specifies the location where Model RealTime is installed. The model compiler may need this information in case the built model references something that is located in the Model RealTime installation.
--ruleConfiguration=<rules> This option can be used for configuring which validation rules the model compiler should check the input model against. In case a rule fails and a problem will be reported, the option can also specify which severity the problem should have (Information, Warning or Error). The <rules> is a comma-separated list of rule ids prefixed with with one of the following letters:
  • X: Disable the validation rule,
  • E: Set the severity to Error,
  • W: Set the severity to Warning,
  • I: Set the severity to Information.
Example: 
X0001,W0002,E0003
(disable rule 0001, enable rule 0002 as Warning, and enable rule 0003 as Error). You should only configure a rule once, but if you do it multiple times, the last configuration will take precedence. The id of a rule can be seen from the message that gets printed when the rule is enabled and fails.
--syncMap=<path> This option is used when the model compiler is launched by Model RealTime in order to request it to print certain information that is needed for code-to-model synchronization. You don't need to use this option yourself when calling the model compiler.
--timing=<file> Prints information to a file about the time it took to run the model compiler. This option may be useful if you want to test so that build times remain acceptable when making changes to your models or the build system.
--validate=<rule> Sets the validation rules to be performed by the model compiler. The following rules are supported:
  • sources - Validate source model elements and report errors if any source element is missing.
  • tc - TC files are validated. You can set multiple rules separated by a comma. Set the scope to off in order to disable all validation. By default, all validations are turned on.
--verbose=<level> Sets the verbosity of the model compiler. The following verbosity levels are supported:
  • default - By default, the model compiler is rather verbose and prints several information messages to the console to indicate its progress. This level is appropriate when running the model compiler as a stand-alone tool from the command-line.
  • makefile - Disables all console printouts. This level is typically appropriate when the model compiler is invoked from a make file, which may have its own printouts.
--version Prints the version of the model compiler.