VMake has built-in support for some automatic code generators. UNFUG (see Section 6.1) and TAC (see Section 6.2) are part of VMake itself and are written in LISP. They use the same VLisp interpreter as VMake. UNFUG uses a template/tuple approach as shown in Fig. 4.1.
Abbildung 4.1: Information flow for UNFUG
The placeholders in the template files are replaced by the actual values from the tuple file to produce the output file. An optional LISP file can be loaded for additional functions which can be used during replacement of the placeholders.
The tool TAC extracts information from sources to create language binding as shown in Fig. 4.2. The source file is parsed in Step 1 for special comments for documentation and binding information. This extracted information is used in Step 2 to create the actual language binding or the reference documentation. The internal information file is used to transfer the TAC information between different projects.
Abbildung 4.2: Information flow for TAC bindings
Other tools like YACC, LEX, AWK and PERL (see Section 6.3) use external executables which must be defined by the configuration. They take one or more input files to create output. Care should be taken using these code generators because usually they are only available for UNIX, and not all options might be available for all platforms. During generation of a release or a patch, the automatically generated code is copied to the released project too.
Automatically generated files should have a file extension starting with ``a'' in addition to the standard extension to mark the file as automatically generated. VMake protects these files from unintentional changes by removing the write privilege of the file. VMake distinguishes between automatically generated code that can be shared between configurations and code which is configuration dependent because it uses platform specific information during creation. In addition output of executables can be marked configuration dependent.
Unfug-Target
This rule allows to generate a file or a set of files with UNFUG.
The key target describes the automatically generated output files
associated to the symbolicName. VMake checks whether all output files
are created by the UNFUG execution.
The key template defines the template file for code generation and the key tuple the optional tuple files. Additional LISP code files may be loaded by the key load.
The functionality of UNFUG is described in Section 6.1.
VLisp-Target
This rule uses the VMake executable as a LISP interpreter for
automatic code generation.
The key target defines the files which are generated from the
LISP source files specified by the key source. VMake
automatically checks whether all output files are created. Additional
LISP files may be preloaded by using the key load.
The key arguments is used to specify arguments for the executing LISP program specified by the key source. These arguments are not used by the interpreter itself.
Define-TAC-Interface
This rule implements the first step of the TAC language binding
mechanism. The full process of language binding is explained in
Section 6.2.
The key source-domain defines the source language of the files
given by the key source for cross checking. Instead of the source
files, the symbolicName associated with the compiled object files may be
specified. Combining sources from different source languages is not
allowed. The extracted information is associated to the symbolicName for
later language binding with the Create-TAC-Interface. The scope of
this symbolicName is global to all parent projects and the information
file is marked for installation.
From the key module the system dependent file name for storing the extracted information is derived.
The key depends defines dependences of these TAC definitions on other interfaces, e.g., on types created in other definitions.
The key newtypes informs TAC, that new data types are used in
the TAC binding in combination with the
Create-TAC-Interface. The following files are required or optional
for new type definitions depending on the target domain:
The information stored in these files is described in
Section 6.2.2. A source or target domain PASCAL is currently not
supported. For additional source and target domain combinations
the TAC must be enhanced.
Create-TAC-Interface
This rule creates the binding code for a certain TAC definition between
the target domain and the source domain defined by
Define-TAC-Interface.
The key modules are symbolicNames defined by the
Define-TAC-Interface. They define the modules for which the
binding is generated.
The key target-domain is used to define the target language of the binding.
The string of the key binding is used as base name for the different generated files. For FORTRAN target domain a ``binding.INC'', for a C target domain, a ``binding.ah'' is generated. The a VLisp binding the name is used in the generated binding source file.
The keys flags and defines are used to compile the generated binding code with the C or C++ compiler depending on the source domain defined by Define-TAC-Interface. For a FORTRAN source domain a C binding source file is generated and compiled with the C compiler.
The generated include files are automatically exported to parent projects. This behavior can be overridden by the key project to force them to the project local.
Yacc-Target
This rule generates a parser using the YACC compiler and a description
file. The compiler is defined in the configuration definition and must be
accessible from the current environment.
The key yacc defines the YACC parser source file. The source is
installed globally as an example if the key example is used.
The key prefix can be used to override the default prefix ``yy'' for the generated parser functions and variables.
The optional include file with parser definitions will be generated if the boolean key include is given. The keys global and project override the default local include file to be exported or to be project wide available.
The keys flags and defines are used for compilation of the automatically generated C, or if key c++ is given C++, source file. Generating an object oriented C++ parser is known to be supported only by BISON, the GNU extended version of this tool and should be avoided whenever possible.
Lex-Target
This rule generates a lexical analyzer from the description file using the
LEX program. The analyzer is defined in the configuration definition and
must be accessible from the current environment.
The key lex defines the LEX analyzer source file. The source is
installed globally as an example if the key example is used.
The key prefix can be used to override the default prefix ``yy'' for the generated analyzer functions and variables.
The keys flags and defines are used for compilation of the automatically generated C, or if key c++ is given C++, source file. Generating an object oriented C++ lexical analyzer is known to be supported only by FLEX, the GNU extended version of this tool and should be avoided whenever possible.
Awk-Target
This rule supports the AWK script interpreter for automatic code
generation. The interpreter is defined in the configuration definition and
must be accessible from the current environment.
The key awk defines the script file used by AWK for automatic
code generation.
The key inputs can be used to specify optional input files for the script. Additional AWK definitions are specified by the key define.
The key outputs lists all files generated by the AWK script. VMake automatically checks whether all output files are created.
Perl-Target
This rule supports the script interpreter PERL for automatic code
generation. The interpreter is defined in the configuration definition and
must be accessible from the current environment.
The key perl defines the script used by PERL for automatic code
generation. The key arguments specifies command line arguments for
PERL.
The key inputs defines the input files for the PERL script.
The key outputs lists all files generated by the PERL script. VMake automatically checks whether all output files are created.
Filter-Target
This rule allows to execute an external program or shell script to implement
a generic filter target.
The key filter is the symbolicName of an external program or
script defined by External-Program (see
External-Program). The key arguments can be used to
create a full command line for the filter program.
Each file listed by the key source is passed to the filter program. The output file name is constructed from the source file with the new file extension defined by the key newext.
The key remove can be used to remove temporary files from the filter program. No wildcard expression is allowed in these file names.