t2c - a tool for file generation using “Template-to-Code” approach.
Usage:
t2c [options] {suite_root_dir} [t2c_file_path]
Options:
-d dir, --templates=dir
Load templates from directory dir instead of the default one. This can be convenient if one needs to override most or all the templates provided with t2c or to add new file generation targets.
-t target_name, --target=target_nameGenerate files for the specified target.
Each T2C target (or “profile”) is just the name of the collection of templates to be used to create output files. The templates are looked for in the subdirectory of main template directory (see above) that is named “target_name”. Different sets of files can be generated for different targets.
Commonly used targets are “c_minimal”, “c_standalone”, “c_tet”, etc. Other targets can be provided by the user.
Note that the file generation target can also be specified in TARGET parameter in the configuration file of the test suite. If so, the target specified in -t (--target) option will be used instead of the one specified in the configuration file.
File generation target must be specified either in the configuration file of the suite or in this option (or may be in both places). Otherwise t2c will not know which templates to use and will complain about it.
-f file, --list-file=file
Define a parameter named TEST_MODULE and populate it with the records from file. The parameter may be multivalued as a result. This can be useful to create the list of test executables, etc. The records are sequences of characters separated by spaces, tabs and/or newline characters.
If the specified file is missing or contains only spaces, tabs and/or newline characters, it is not considered an error. TEST_MODULE will just have an empty value in this case.
As whitespace characters are used as separators in the file, currently there is no way to populate TEST_MODULE parameter with the values containing such characters.
--versionDisplay version information and then exit.
--print-data-dirDisplay the path to the data directory of T2C and then exit. This can be useful, for example, to find the directory where the sources of T2C API libraries are located. If an API Library is provided for a file generation target, it is located in the following directory:
`t2c --print-data-dir`/api/
target_name
The templates for that target can be found in the following directory:
`t2c --print-data-dir`/templates/
target_name
--helpDisplay this information and then exit.
t2c works as follows. It loads the appropriate templates, reads data from the configuration file of the test suite and from the .t2c file (if specified). It then creates output files based on the loaded templates and that data.
t2c expects to find the configuration file for the test suite in suite_root_dir
directory. The file must have extension “.cfg” and the same name as the last component of the path defined by suite_root_dir. If suite_root_dir ends with “-t2c”, this suffix must be omitted from the name of the configuration file.
For example, the expected path to the configuration file for the suite located in work/suite-t2c is work/suite-t2c/suite.cfg. For work/another_suite, however, it is work/another_suite/another_suite.cfg
Typically, one may need to execute t2c several times:
Execute t2c without t2c_file_path argument to create common files for the test suite (“common mode”): top-level Makefiles and configuration files of the test suite, common source files, etc. You may also want to use -f (--list-file) option in this case to specify the list of names of the .t2c files to which the generated common files correspond. This can be necessary, for instance, to create the list of the source files of the tests to be built or the list of test executables to be run by make check and so on.
Example:
t2c -f work/suite-t2c/test_groups.list work/suite-t2c
The file work/suite-t2c/test_groups.list might contain something like the following in this case:
foo
bar
baz
That is, it contains just the names of the corresponding .t2c files (without “.t2c” extension) separated by spaces, tabs or newline characters.
Execute t2c for each .t2c file in the suite to create test-specific files (“test mode”): the sources of the tests, per-test makefiles, etc.
Example:
t2c work/suite-t2c work/suite-t2c/src/foo.t2c
t2c work/suite-t2c work/suite-t2c/src/bar.t2c
t2c work/suite-t2c work/suite-t2c/src/baz.t2c
...
suite_root_dir specifies the root directory of the test suite. It contains a configuration file and a number of other files and directories (see the typical directory structure of a test suite for details).
It is allowed for t2c_file_path to specify a location outside of suite_root_dir. It is not mandatory to store .t2c files inside of the test suite although it is often convenient to do so.
It is not mandatory for a .t2c file to have “.t2c” extension.
If -d (--templates) option is present, the directory specified there is used as the main template directory instead of the default one.
If -t (--target) option is present, the files are generated for this target instead of the one specified in TARGET parameter in the configuration file of the test suite.
Generally, the templates are loaded from the following directory:
template_directory/target/modemode is “common” or “test” (without quotes).
Example:
/opt/t2c/share/templates/c_tet/common (main template directory is /opt/t2c/share/templates, target is “c_tet”, mode is “common”).
If T2C_DATADIR environment variable is defined and is not empty, t2c will use the value of this variable as the path to its data directory instead of the default path. You can execute t2c --print-data-dir to see which directory will be used as the data directory (see the description of --print-data-dir option above for details).
The default data directory is determined as follows. If APPDATA environment variable is defined, is not empty and its value is a path to a directory containing a subdirectory named t2c, this subdirectory is used as the data directory. This can be useful, for example, on Microsoft Windows systems.
Otherwise, a path specified when t2c was being built is used.
If t2c has successfully generated files (or displayed requested information - see the description of the options above), it exits with status 0. An exit status 1 will be returned if any errors are encountered.