YumaPro yangdump-pro Manual¶
yangdump-pro Introduction¶
The yangdump-pro program is used to validate YANG files, and convert them to other formats. It is normally used by authors while developing new YANG data models. The compiler and validation engine portion of yangdump-pro (libyumapro_ncx.so) is used in all YumaPro programs.
Note
Any place the program name “yangdump-pro” is mentioned, it also applies to the name “yangdump-sdk”, except where explicitly mentioned.
yangdump-pro Features¶
The yangdump-pro compiler has the following features:
full support for all YANG language constructs.
full support for YANG submodules.
full support for YANG revisions and deviations across an arbitrary set of YANG files.
validates the entire YANG source file, even statements within unused objects.
builds a complete internal representation of the 'cooked' object tree, including deviations, to validate or output the exact data structures that result from a set of YANG files.
Over 100 separate validation checks, errors, and warnings, covering every type of programming mistake that can be made in a YANG file.
Some warnings are fully configurable, and any warning can be suppressed.
Can process any number specific modules and directory trees containing modules at once.
Any number of modules containing deviations can be specified, and any target nodes in all modules affected will be properly patched.
Ignores CVS and subversion directories, if encountered in directory searches.
Attempts to find all errors and warnings possible in the file, instead of stopping on the first error.
Verifies that all YANG statement syntax is correct, according to the specification.
Verifies that all YANG typedef statements are correct:
The entire typedef chain is checked, until a built-in data type is reached.
Checks valid combined refinements to named types and built-in types
Check for valid range statements.
Check for valid pattern statements.
Verify the path statement is correct for leafref type statements.
Verify the default statement is valid.
Compile time loop detection:
import statement loops.
include statement loops.
belongs-to statement references self.
typedef type statement references self.
derived type statement loops.
path statement loops for leafref objects.
base statement loops for identity statements.
feature name reference loops for if-feature statements.
uses statement loop in groupings.
Compile-time duplicate detection:
import statements
include statements
must statements
if-feature statements
unique statements
local typedef of grouping name collision
verifies that the correct number of instances appear for every YANG sub-statement.
duplicate sibling node names due to uses or augment statement expansion
checks multiple refine statements within a uses statement for duplicate refinements to the same target node.
checks multiple deviate statements within a deviation statement for duplicate alterations to the same target node.
checks deep within all choice statements to make sure that no accessible object names conflict with sibling nodes that will appear in the value nodes, within a NETCONF database.
Verifies that all default statements are correct for the declared type.
Only the static properties of the leafref and instance-identifier built-in data types can be validated at compile time.
Verifies that all XPath expressions in must and when statements, even those in groupings, contain only valid XPath and reference valid data nodes.
Verifies all when statements for a given cooked object, even those inherited from uses and augment statements.
Detects namespace statement conflicts across a set of modules.
Detects prefix statement conflicts across a set of modules.
Detects augment statement conflicts.
Checks if any key leafs are more conditional than their parent node. This can occur if any 'when' or 'if-feature' statements apply to the key leaf, but not to the parent.
Detects unused typedefs and groupings.
Checks line length and identifier length.
Checks revision statements present and in correct order.
Detects any top-level mandatory configuration objects:
leaf with mandatory statement set to true.
choice with mandatory statement set to true.
non-presence container with any mandatory descendants.
Checks all refine statements for proper usage, and checks that the resulting set of objects remains valid. Multiple refine statements for the same target will be combined and checked as if there was only one refine statement for each target node.
Checks all deviation statements for proper usage, and checks that the resulting set of objects remains valid. Multiple deviation statements for the same target will be combined and checked as if there was only one deviation statement for each target node.
Generates doxygen headers for all the functions in the SIL or SIL-SA source code
format must be set to one of the C file variants
doxygen-headers must be set to true (default)
The yangdump-pro translator has the following features:
Full support for YANG string specification syntax:
All double quoted string formatting rules.
Preservation of single-quoted string content.
All forms of string concatenation.
Unquoted string without any whitespace.
Generates YIN syntax from the YANG token sequence
YIN format is the standard XML version of a YANG module
Generates hyper-linked HTML for a set of YANG modules.
Rich set of configuration parameters to control HTML generation.
Uses configurable and customizable Cascading Style Sheets (CSS).
Can generate full WEB page or single <div> for embedding in a WEB page.
Can combine all sub-modules into a single conceptual module.
Objects tagged as ncx:hidden will be ignored in the HTML output.
Generates canonical YANG (all statements in the same order, etc.):
Combines refine and deviation statements for the same target.
Combines range statement components into canonical form.
Generates consistent (configurable) indentation for all statements.
Objects tagged as ncx:hidden will be ignored in the YANG output.
Generates SQL statements for populating the netconf-central database with quick lookup information about a set of YANG modules.
Generates C source code stubs for netconfd-pro server instrumentation libraries, for dynamic loading of a YANG module.
Generates informational reports on the contents of a YANG file:
Imported modules (dependencies).
Exported symbols (exports).
Object name tree (identifiers or tree-identifiers)
Module revision date (modversion)
YANG module metrics reports (stats and totals)
Starting yangdump-pro¶
The current working directory in use when yangdump-pro is invoked is important. It is most convenient to run yangdump-pro from a work directory, rather than the installation directory or within the module library.
The yangdump-pro program can be invoked several ways:
To get the current version and exit:
> yangdump-pro --version
To get program help and exit:
> yangdump-pro --help > yangdump-pro --help --brief > yangdump-pro --help --full
The default parameter for the yangdump-pro CLI is the --module parameter. If an unknown parameter is given and it could be a valid module parameter, then it will be treated as an instance of this parameter.
To validate a single YANG module named 'foo', the following command lines are equivalent:
> yangdump-pro foo > yangdump-pro --module=fooTo validate the './test1' and './test2' directory subtrees as an entire set of modules, and save the output to 'mylogfile':
> yangdump-pro --subtree=test1 --subtree=test2 --logfile=mylogfile
To get all the configuration parameters from a text file named '~/yangdump-pro-project1.conf':
> yangdump-pro --config=~/yangdump-pro-project1.confTo generate YANG HTML documentation files in the '~/work' directory (with the default naming scheme) for all the YANG modules in the './test1' directory subtree:
> yangdump-pro --subtree=test1 --output=~/work --format=html --defnames=true
Stopping yangdump-pro¶
There is no interactive mode for yangdump-pro, so there is no need for a command to exit the program.
The Control C character sequence can be used to cancel the yangdump-pro processing in progress. However, this will leave any partially completed output files in place.
Configuration Parameter List¶
The following configuration parameters are used by yangdump-pro. Refer to the CLI Reference for more details.
yangdump-pro CLI Parameters
Parameter |
Description |
|---|---|
Specifies the configuration file to use for parameters. |
|
Specifies if the default naming scheme is used for any output files. |
|
Generate the module dependencies report. |
|
Species one or more YANG modules to load as deviations. |
|
Specifies if doxygen comment headers should be used when generating source code |
|
Generate the module exports report. |
|
Specifies if a feature should use static or dynamic code by default |
|
Leaf list of features to disable |
|
Specifies a feature that uses dynamic code |
|
Specifies a feature that should be enabled |
|
Specifies if a feature should be enabled or disabled by default |
|
Specifies a feature that uses static code |
|
Specifies the type of translation format that should be used for the output. |
|
Specifies the prefix to use for short name generation |
|
Get context-sensitive help, then exit. |
|
Adjust the help output (--brief, or --full). |
|
Override the $HOME environment variable |
|
For HTML translation, controls whether to generate a <div> element instead of a complete HTML document. |
|
For HTML translation, controls the table of contents that is generated. |
|
Generate the module object identifiers report. |
|
Specifies the indent count to use when writing data. |
|
Generate the default error messages for language translation |
|
Specifies the log file to use instead of STDOUT. |
|
Controls whether a log file will be reused or overwritten. |
|
Specifies verbosity level of log message output |
|
Sets the module search path. |
|
Specifies one or more YANG modules to load upon startup. |
|
Generate the module version report. |
|
Ignore the default config file if it is present. |
|
Specifies whether raw or cooked objects will be generated during HTML and YANG translation. |
|
Specifies where output files should be generated. |
|
Do not generate module summary reports unless errors or warnings found |
|
Specifies if short name code generation will be used |
|
Print all the error and warning messages, then exit. |
|
Generate a SIL or SIL-SA bundle instead of a library for 1 module |
|
Generate a first generation edit function callback instead of 2nd generation |
|
Generate a 2nd generation edit function callback instead of first generation |
|
Generate a first generation get function callback instead of 2nd generation |
|
Generate a 2nd generation get function callback instead of first generation |
|
Generate an 'include' directive in the SIL or SIL-SA C files |
|
Generate NMDA related code within SIL or SIL-SA GET2 functions |
|
Generate SIL-SA (sub-agent) code instead of SIL (master agent) code |
|
Controls how URL parameters are generated during HTML file output. |
|
Control YANG usage statistics reporting for each input module. |
|
Controls whether sub-directories will be searched during file searches. |
|
Specifies one or more directory subtrees to search for YANG modules. |
|
Controls statistics summary reporting for a set of input modules. |
|
Generate the module object identifier local-names report in tree format. |
|
Controls whether to combine submodules into the main module in the translation output. |
|
Specifies the start of URLs to use during HTML file generation. |
|
Prints the program version and then exit. |
|
Controls whether the revision date is used in YANG module file names. |
|
Treat all warnings as errors |
|
Controls how identifier lengths are checked. |
|
Controls how line lengths are checked. |
|
Suppresses the specified warning number. |
|
Elevates the specified warning number to an error |
|
Controls whether OpenConfig pattern syntax will be checked |
|
Generate schemaLocation attributes during XSD translation. |
|
Specifies the $YUMAPRO_HOME project root to use when searching for files. |
Validating YANG Files¶
The yangdump-pro program will always validate the modules specified in the configuration parameters, unless one of the quick exit modes is requested (--version or --help). If a valid --format parameter is present, then some sort of translation will also be attempted.
The modules or submodules to validate are specified with the --module and/or --subtree configuration parameters.
All sub-modules that are included, and all modules that are imported, are also validated. This is done in the order the import or include statements are encountered. Errors and warnings that occur in included submodules or imported modules may be repeated, if it is used more than once within the requested set of files to validate.
The netconfd-pro server will refuse to run if any of its core YANG modules contain any errors, as reported by the yangdump-pro parser.
The --deviation parameter is used to specify any YANG module files that contain YANG deviation statements, which may apply to any of the modules specified with the --module or --subtree parameters. Modules parsed as deviation files are not validated. Imported modules are not actually read, and therefore not validated either.
A module can appear in the deviation list and the module or subtree module list. The deviation statements will simply be processed separately from the other YANG statements found in the file.
If all the deviation statements for a module appear in the same module as the objects that are the target(s) of the deviations, then the --deviation parameter does not need to be used.
There is no way to specify the exact revision date associated with each file, at this time. The module search path needs to be configured such that the module search algorithms will find the appropriate versions.
This only applies if the revision-date statement is not present in the import statement, of course. Otherwise, only the specified revision-date will be used, or an error will be generated if the exact import file was not found.
yangdump-pro Validation Messages¶
A error is generated, and the error count for the module is incremented, if any violation of the YANG standard is detected.
A warning is generated, and the warning count for the module is incremented, if:
any suspected misuse of the YANG standard is detected.
any YANG statements which have no affect are detected.
any duplicate statements which may conflict with previous statements are detected.
any violation of a YANG usage guideline is detected.
any statements which may cause operational conflicts, due to duplicate values from another module is detected. The module prefix or an augment statement which adds a node with the same name are examples of this type of operational conflict.
An informational message is generated if any potentially interesting conditions or abnormality is detected.
A debugging message is generated if available, to track the internal behavior of the yangdump-pro parser.
The default --log-level configuration parameter value is 'info'. It is strongly suggested that the log-level not be set to 'off' or 'error'. Instead, set the log level to at least 'warning', and use the --warn-error, --warn-idlen, --warn-linelen, --warn-off, and --warn-up configuration parameters to suppress or modify specific warning messages.
Generally, a context-specific error message is generated, followed by a structured error message.
A context-sensitive error message will begin "Error: ....".
A structured error message will begin with a line in the following format:
<module>:<line-number>:<column-number>: error(<error-number>):<msg>
where:
module is a module or submodule name
Validation Example¶
The following example shows the error messages that are generated for
the 'testloops.yang' file, usually installed at
/usr/share/yumapro/modules/test/fail/testloops.yang.
user1$ yangdump-pro testloops
Error: import 'testloops' for current module testloops.yang:6.5: error(327): import loop
Error: include 'testloops' for current submodule testloops.yang:10.5: error(328): include loop
Error: if-feature loop detected for 'A' in feature 'C' testloops.yang:66.5: error(325): definition loop detected
Error: typedef 'typeloop' cannot use type 'typeloop' testloops.yang:35.8: error(325): definition loop detected
Error: named type loops with type 'typeloop2' on line 43 testloops.yang:47.8: error(325): definition loop detected
Error: uses of 'grouploop' is contained within that grouping, defined on line 50 testloops.yang:51.8: error(325): definition loop detected
Error: grouping 'grouploop2' on line 54 loops in uses, defined in module testloops, line 63 testloops.yang:54.5: error(325): definition loop detected
Error: grouping 'grouploop3' on line 58 loops in uses, defined in module testloops, line 55 testloops.yang:58.5: error(325): definition loop detected
Error: grouping 'grouploop4' on line 62 loops in uses, defined in module testloops, line 59 testloops.yang:62.5: error(325): definition loop detected
Error: leafref path in leaf LR1 loops with leaf LR3 testloops.yang:16.5: error(359): leafref path loop
Error: leafref path in leaf LR2 loops with leaf LR1 testloops.yang:22.5: error(359): leafref path loop
Error: leafref path in leaf LR3 loops with leaf LR2 testloops.yang:28.5: error(359): leafref path loop
* /usr/share/yumapro/modules/test/fail/testloops.yang * 12 Errors, 0 Warnings user1$
Translating YANG to Other Formats¶
The yangdump-pro program can be used to translate YANG files to other formats, using the --format parameter. This section describes the available translation modes.
In all cases:
the :ref:--subtree` or --module parameter is required to specify the input files. Any number of these parameters can be entered, given in any order.
the --deviation parameter will affect how objects are generated, if --objview=cooked.
the --output parameter is usually specified to cause the files to be copied to a different directory. If this parameter is not present, then the current directory will be used for generation of output files. The default is either STDOUT, or to the current directory if --defnames is set to 'true'.
the --indent parameter can be used to specify the number of spaces to indent each new nest level. The default value is 3 spaces.
the --defnames parameter can be used to force the default naming scheme. For many translation modes, this parameter is the assumed default, and cannot be changed.
the --urlstart parameter can be used to specify the string to start all URLs, if URLs are generated in the output.
YIN Format¶
The standard YIN format can be generated with the --format=yin parameter value.
The YIN representation of a YANG module is an XML instance document consisting of a <module> or a <submodule> element.
The set of YANG prefixes used in the module will be used as the XML prefixes available in the document. These namespace attributes are added to the top-level element for the module prefix and any imported modules.
The following example shows the XML instance document that is generated for --module=test4 and --format=yin:.
> yangdump-pro --module=test4 --format=yin --output=test4.yin
The file "test4.yin" will be created with the following contents:
<?xml version="1.0" encoding="UTF-8"?>
<module
name="test4"
xmlns="urn:ietf:params:xml:ns:yang:yin:1"
xmlns:t4="http://netconfcentral.org/ns/test4">
<namespace uri="http://netconfcentral.org/ns/test4" />
<prefix value="t4" />
<revision date="2009-09-09">
<description>
<text>Initial revision.</text>
</description>
</revision>
<typedef name="aa-type">
<description>
<text>test type</text>
</description>
<type name="int32">
<range value="1..10 | 20..30" />
</type>
</typedef>
<container name="a">
<leaf-list name="aa">
<type name="aa-type" />
<max-elements value="5" />
</leaf-list>
</container>
<leaf name="b">
<type name="leafref">
<path value="../a/aa" />
</type>
</leaf>
<list name="c">
<key value="x" />
<leaf name="x">
<type name="uint16" />
</leaf>
<leaf name="y">
<type name="instance-identifier" />
</leaf>
</list>
</module>
HTML Translation¶
xHTML 1.0 files can be generated by using the --format=html parameter value.
An HTML version of a YANG file will contain color-coded YANG tokens to make the file easier to read. There will also be links created whenever possible, for statements which reference typedefs, groupings, extensions, etc.
The following configuration parameters are available to control some of the details:
--html-div: If 'true', create a single <div> element that can be integrated into other WEB pages. The default is 'false', to create an entire WEB page (<html> element).
--html-toc: controls how (or if) a table of contents section is generated. The default is to create a drop-down menu type ToC, which requires that Javascript is enabled in the browser.
--objview: controls whether raw (with uses, augments, refine, and deviation statements) or cooked (final object tree without uses, etc). The default is the 'raw' (original) view.
--simurls: controls how URLs with parameter fragments are generated. The default is 'false', which is to use traditional encoded parameters.
--unified: controls whether submodules are combined into the main module, or if the 'include' statements are left in place. The default is 'false', to treat each file separately, and not expand any include statements.
--urlstart: specifies the string that starts every generated URL in all A and HREF attributes. There is no default for this parameter.
The following example shows the HTML that is generated for --module=test4, using default values for all HTML generation parameters:
> yangdump-pro --module=test4 --format=html --output=test4.html
The file "test4.html" will be created with the following contents:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>YANG Module test4 Version 2009-09-09</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<meta name="description" content="YANG data model documentation"/>
<meta name="generator" content="yangdump 21.10-3 (http://www.netconfcentral.org/)"/>
<link rel="stylesheet" href="http://netconfcentral.org/static/css/style.css" type="text/css"/>
</head>
<body>
<h1 class="yang">test4@2009-09-09</h1>
<ul id="nav">
<li><a href="#">Typedefs</a>
<ul>
<li><a href="#aa-type.10">aa-type</a></li>
</ul>
</li>
<li><a href="#">Objects</a>
<ul>
<li class="daddy"><a href="#a.15">a</a>
<ul>
<li><a href="#aa.16">aa</a></li>
</ul>
</li>
<li><a href="#b.22">b</a></li>
<li class="daddy"><a href="#c.26">c</a>
<ul>
<li><a href="#x.28">x</a></li>
<li><a href="#y.29">y</a></li>
</ul>
</li>
</ul>
</li>
</ul>
<br />
<div class="yang">
<pre>
<span class="yang_kw">module</span> <span class="yang_id">test4</span> {
<span class="yang_kw">yang-version</span> <span class="yang_str">1</span>;
<span class="yang_kw">namespace</span>
<span class="yang_str">"http://netconfcentral.org/ns/test4"</span>;
<span class="yang_kw">prefix</span> <span class="yang_str">t4</span>;
<span class="yang_kw">revision</span> <span class="yang_str">"2009-09-09"</span> {
<span class="yang_kw">description</span> <span class="yang_str">"Initial revision."</span>;
}
<a name="aa-type.10"></a><span class="yang_kw">typedef</span> <span class="yang_id">aa-type</span> {
<span class="yang_kw">type</span> <span class="yang_id">int32</span> {
<span class="yang_kw">range</span> <span class="yang_str">"1..10 | 20..30"</span>;
}
<span class="yang_kw">description</span> <span class="yang_str">"test type"</span>;
}
<a name="a.15"></a><span class="yang_kw">container</span> <span class="yang_id">a</span> {
<a name="aa.16"></a><span class="yang_kw">leaf-list</span> <span class="yang_id">aa</span> {
<span class="yang_kw">type</span> <span class="yang_id"><a href="#aa-type.10">aa-type</a></span>;
<span class="yang_kw">max-elements</span> <span class="yang_str">5</span>;
}
} <span class="yang_cmt">// container a</span>
<a name="b.22"></a><span class="yang_kw">leaf</span> <span class="yang_id">b</span> {
<span class="yang_kw">type</span> <span class="yang_id">leafref</span> {
<span class="yang_kw">path</span> <a href="#aa.16"><span class="yang_str">"../a/aa"</span></a>;
}
}
<a name="c.26"></a><span class="yang_kw">list</span> <span class="yang_id">c</span> {
<span class="yang_kw">key</span> "<a href="#x.28">x</a>";
<a name="x.28"></a><span class="yang_kw">leaf</span> <span class="yang_id">x</span> {
<span class="yang_kw">type</span> <span class="yang_id">uint16</span>;
}
<a name="y.29"></a><span class="yang_kw">leaf</span> <span class="yang_id">y</span> {
<span class="yang_kw">type</span> <span class="yang_id">instance-identifier</span>;
}
} <span class="yang_cmt">// list c</span>
} <span class="yang_cmt">// module test4</span>
</pre>
</div>
</body>
</html>
The following picture shows how this WEB page looks in a WEB browser:
XSD Translation¶
Note
Note: This feature is obsolete and no longer supported. Do not use.
SQL Translation¶
Note
SQL translation is reserved for future use. The --format=sql enumeration is not supported.
SQL Documentation Database Translation¶
SQL documentation database translation for the Netconf Central documentation database can be generated using the --format=sqldb parameter value.
Canonical YANG Translation¶
Note
This feature is deprecated. Do not use!
Canonical YANG files can be generated by using the --format=yang parameter value.
In this translation mode, all YANG constructs are generated in the same order, with the same indentation.
The order used is the order defined in the YANG specification ABNF. The order is somewhat arbitrary, but the purpose of this translation mode is to generate consistent documentation.
Normally, the order of top-level statements within a module is preserved in the canonical YANG translation. Only the sub-statements within the top-level statements may be reordered. Child objects are never reordered, just the sub-statements within them.
Range statements will be converted to canonical form. If there are contiguous range parts, then they will be combined.
Note
Comments are not preserved in the translation.
Example range statement:
range "1 .. 10 \| 11 \| 12 .. 20";
Canonical form for this example:
range "1 .. 20";
If the --unified parameter is set to 'true', then all statements of a similar type will be grouped together, from all sub-modules included by the main module.
The ncx:hidden extension will cause objects containing this extension to be omitted during translation.
Copy and Rename YANG Files¶
Exact copies of a YANG file can be copied to another directory and renamed to the default naming scheme, using the --format=copy parameter value.
Only YANG files that have no errors will be copied. If the validation phase produces a non-zero error count, then the file will not be copied and renamed.
The --defnames parameter is set to 'true' in this mode. The default YANG file names will be created for each input file.
Example file foo.yang:
module foo {
namespace http://example.com/ns/foo;
prefix foo;
// header skipped
revision 2009-02-03 {
description "Initial version";
}
}
Example renamed file, if --output=~/workdir:
If --versionnames=true:
~/workdir/foo.2009-02-03.yang
If --versionnames=false:
~/workdir/foo.yang
Server SIL and SIL-SA Code Generation¶
The yangdump-pro program can be used to generate C code-stub files for the netconfd-pro server.
Note
The yangdump-sdk program is identical to yangdump-pro, starting in the 21.10-4 release.
Normally a SIL file is generated for a single YANG module. However this does not allow SIL code for external augmentation statements to be generated. In order to generate SIL code for a set of modules, such as a base module and 1 or more modules that augment the main module, the --sil-bundle parameter must be used.
The SIL bundle name must be different than all the module names in the bundle. A H and C file will be generated for the SIL bundle initialization and cleanup hooks (with make_sil_bundle). If the bundle name is 'bundle1', then there will be files created called y_bundle1.c and y_bundle1.h.
The following scripts are installed to help create complete SIL directories. The yangdump-sdk program is invoked multiple times to generate each type of of file each time (e.g, C and H).
make_sil_bundle
make_sil_dir_pro
make_sil_sa_bundle
make_sil_sa_dir
There are 2 modes of operation:
split-mode: The SIL code is split into user and system files. This is the recommended and default approach.
combined-mode: SIL modules contain the user and system callback functions combined. This mode is not recommended since the list keys are not automatically handled in this mode.
Note
The combined mode is now deprecated. The split mode is now the default, starting in 21.10-1.
To inject C “include statements” into the C files that are generated, use the --sil-include parameter.
Note
Code generation defaults have changed starting in the 21.10-1 release.
sil-edit2 is the default so it can be omitted
sil-get2 is the default so it can be omitted
To generate GET1 functions, use the –sil-get1 parameter
To generate EDIT1 functions, use the –sil-edit1 parameter
Server Instrumentation H File Generation¶
There are 4 different parameters for generating SIL developer H files:
--format=h |
Generate combined User and YumaPro SIL H file |
--format=uh |
Generate split User SIL H file |
--format=yh |
Generate split YumaPro SIL H file |
--format=bh |
Generate a SIL bundle H file |
These parameter values are only relevant for YumaPro server developers. Refer to the YumaPro Developer Manual for more details.
Server Instrumentation C File Generation¶
There are 4 different parameters for generating SIL developer C files:
--format=c |
Generate combined User and YumaPro SIL C file |
--format=uc |
Generate split User SIL C file |
--format=yc |
Generate split YumaPro SIL C file |
--format=bc |
Generate a SIL bundle C file |
These parameter values are only relevant for YumaPro server developers. Refer to the YumaPro Developer Manual for more details.
There are 6 additional parameters for modifying how SIL developer code will be generated:
Parameter |
Description |
|---|---|
Generate code for multiple modules instead of 1 module |
|
Generate 2nd generation edit callbacks instead of 1st generation |
|
Generate 2nd generation get callbacks instead of 1st generation |
|
Generate an 'include' directive for the specified header |
|
Generate additional NMDA code in GET2 functions |
|
Generate SIL-SA code instead of SIL code |
Doxygen Header Generation¶
The Doxygen program is a widely available open-source program for generating source code documentation.
The auto-generated SIL or SIL-SA code now includes doxygen formatted header comments by default. To turn this feature off, use the --doxygen-headers=false setting, and the original style comments will be generated instead.
Refer to the YumaPro Doxygen Browser section of the YumaPro Developer Manual for more details.