EMBEDDED C CODE¶

::critcl::ccode text

This command compiles the C code in text and makes the contained definitions (variables, functions, macros, etc.) available to all C code fragments specified after it. It itself can assume to have access to all definitions which were specified before it. See section Runtime Behaviour for more details.

The result of the command is the empty string.

::critcl::ccommand tclname cfunname

This command creates a new Tcl command named tclname which is implemented by the C function cfunname. It is expected that cfunname has the proper signature for a Tcl command function, and was declared already.

The result of ::critcl::ccommand itself is the empty string.

::critcl::ccommand tclname arguments body ?option value...?

This form of critcl::ccommand creates a new Tcl command named tclname which is implemented by the C code in body.

The command wraps the body in an invisible C function, compiles it and makes the resulting definition available to all C code fragments declared later on. It itself can assume to have access to all definitions which came before it. See section Runtime Behaviour for more details.

The result of critcl::ccommand itself is the empty string.

The list of arguments contain the names for the four parameters required by a Tcl command function. Superfluous list elements (i.e. beyond the fourth) are ignored. Missing elements (parameters), and empty parameter names are handled by replacing them with standard names. These are, in order of usage

The only options accepted by this command are:

A ccommand is, in comparison to functions defined via critcl::cproc, more lower level. Its advantage is that the developer can do their own argument processing, enabling things like variable number of arguments, options, etc., i.e. much higher flexibility. Their disadvantage is that you have to do your own argument processing. Where a critcl::cproc generates the code to convert from Tcl values to C values and back a critcl::ccommand forces the writer to do all of this on their own. I.e. the cost of the aforementioned flexibility is a higher complexity seen by the user.

::critcl::cdata tclname data

This command creates a new Tcl command named tclname which returns data as a ByteArray result.

The result of critcl::cdata itself is the empty string.

::critcl::cconst tclname resulttype value

This command creates a new Tcl command named tclname which returns the constant value as its result, with Tcl type resulttype.

The result of critcl::cconst itself is the empty string.

The command is similar to critcl::cdata in that it returns a constant value. Contrary to critcl::cdata however it is not restricted to ByteArray results, but accepts all result-types known to critcl::cproc. Its semantics are actually equivalent to

    cproc $tclname {} $resulttype "return $value ;"

Contrary to critcl::cproc however it is internally optimized to avoid generating a superfluous C function.

Note that nothing prevents the user from using a C define for the value. Any visible C function is actually also allowed, as long as it does not take arguments.

::critcl::cdefines definitions ?namespace?

This command creates Tcl variables in the specified namespace which are linked to the C enum values and #defines named as glob patterns in the list of definitions. Each variable has the same name as the definition which gave rise to it, and its value is the value of the corresponding enum value or #define. The namespace defaults to the global namespace, i.e. "::", if it wasn't specified explicitly.

Please note that this command is only for the lifting of existing C definitions into Tcl. The command does not create the definitions in C. It actually goes so far to check for the presence of the named definitions and not performing the mapping for any which do not exist. Which is sensible, given that non-existing defines have no value which could be used in the mapping.

As these checks are run at the time the embedded C code of a ".critcl" file is actually compiled they have access to and check all C fragments defined with critcl::ccode, plus all the headers it has access to via critcl::cheaders, for that file.

::critcl::cproc name arguments resulttype body ?option value...?

This command creates a new Tcl command named tclname which is implemented by the C code in body. In contrast to the low-level critcl::ccommand here the arguments and result are typed and critcl generates the code converting from Tcl_Obj's to C data types, and vice versa. The command creates two invisible C functions, one wrapping the body, the other a shim containing the necessary conversions, compiles them and makes the resulting definitions available to all C code fragments declared later on. It itself can assume to have access to all definitions which came before it. See section Runtime Behaviour for more details.

The result of critcl::cproc itself is the empty string.

The only options accepted by this command are:

Below is the list of predefined types legal for resulttype, plus the details of their semantics. Note that it is possible to extend this list with custom types if the standard does not support what is needed. See section Advanced: Extending cproc for details.

The arguments parameter has the overall syntax of a Tcl dictionary value, except that keys (argument names) and values (argument types) are specified in reverse order. Consider the example

int x int y

where

mapped to type/value int.

The argument names must be valid C identifiers.

A limited form of variadic arguments is possible, through optional arguments with default values. For these the argument name is a 2-element list containing the actual name, and the default value. For example, in the declaration

 int {x 1}

x

optional argument of type int and default value 1.

A caveat! The default value is assigned unconditionally. If a custom argument type uses more complex validation, and the default may be invalid according to it, then the relevant checks have to be done in the procedure body. The argument conversion cannot do it as it is completely bypassed when the argument is not present. Overcoming this requires the separation of argument conversion and validation code.

Below is the list of predefined types legal for arguments, plus the details of their semantics. Note that it is possible to extend this list with custom types if the standard does not support what is needed. See section Advanced: Extending cproc for details.

Further note that the type of the first argument is allowed to be Tcl_Interp*. In that case the argument in question is not counted as an argument of the new Tcl command.

typedef struct critcl_pstring {
    Tcl_Obj* o;
    char*    s;
    int      len;
} critcl_pstring;

typedef struct critcl_list {
    Tcl_Obj*  o;
    Tcl_Obj** v;
    int       c;
} critcl_list;

typedef struct critcl_bytes {
    Tcl_Obj* o;
    char*    s;
    int      len;
} critcl_list;

::critcl::cproc name arguments resulttype

This variant of critcl::cproc assumes that the functionality to connect to is implemented by the C function name which has the signature described by the arguments and resulttype.

It creates only the shim performing the conversions required by arguments and result.

::critcl::cinit text externals

This command compiles the C code in text and externals.

Both arguments have access to all definitions created by the previously listed commands, regardless of their placement in the ".critcl" file relative to this command. See section Runtime Behaviour for more details.

The C code in text is put into the body of the initialization function of the shared library backing the ".critcl" file, and is executed when this library is loaded into the interpreter.

This code has access to a variable interp of type Tcl_Interp* referencing the Tcl interpreter currently being initialized.

The code in externals on the other hand is placed outside and just before the initialization function, making this is a good place for any external symbols required by initialization function which should not be accessible by any other parts of the C code.

Multiple invokations of this command are allowed, and a later call has access to the information of all preceding ones.

The result of the command is the empty string.

::critcl::include path

This command is a convenient shorthand for

critcl::code {
  #include <${path}>
}

STUBS TABLE MANAGEMENT¶

Critcl supports this via a single command, critcl::api, and its methods.

First, importing stubs tables, i.e. APIs, from another extension:

::critcl::api import name version

Critcl prepares the ".critcl" file and its companion ".c" files by including the headers

in the appropriate places. It is checked that the compiler will be able to find these header files somewhere on the include search path, using the paths defined so far (See critcl::cheaders, and the critcl application's -I and -includedir options). Note how critcl expects the headers of package foo to reside in a sub-directory "foo" of the known include search paths.

Important: If foo is a namespaced package name, like, for example "c::stack", then the namespace separators "::" are converted into underscores ("_") in path names, C code, etc.

The first header is expected to contain contains all the necessary stubs table type declarations, mapping macros, etc., and may include package specific headers (See critcl::api header below). This header is included at the beginning of the C code backing the ".critcl" file, and at the beginning of all companion ".c" files. This means that the writer of these files doesn't have to write the necessary #include directory, critcl does it for them.

The second header is expected to contain the stubs table variable definition, and the C code, i.e. definition, of the function to initialize it. This, and a call to this initializer function are added to the ".critcl" file's initialization code.

If the directory containing the aforementioned headers also contains the file "name/name.decls" then it is assumed that this file contains the external representation of the stubs table used to generate the headers. The file is read and the internal representation of the stubs table returned as result of the command, for the importing package to use as it sees fit. If no such file is present the command returns the empty string as its result.

One possible use would be the automatic generation of C code calling on the functions listed in the imported API.

When generating a TEA wrapper the names of the imported APIs are used to declare configure options with which the user can declare a non-standard location for the headers of the API. Any API FOO is translated a single configure option --with-FOO-include.

Second, declaration and export of a stubs table, i.e. API, for the current package, foo:

::critcl::api function resulttype name arguments

This method declares that the function name is in the public API of the package, and its signature (type of the result, number, names and types of its arguments). Using this method automatically causes critcl to generate both the code for a stubs table in the package, the headers needed by packages using this API, and a ".decls" file containing the stubs table implied by the exports, usable by critcl::api import.

arguments is a list of C types and associated argument names. Like a dictionary, except that keys (argument names) and values (argument types) are swapped. The resulttype is a C type as well.

::critcl::api header ?pattern...?

This method notifies critcl of companion header files which have to be exported together with the generated stubs headers.

All arguments are interpreted as glob pattern and the matching files are copied into the directory containing the generated headers well. As an importing package uses only "fooDecls.h" to access the API this generated header will contain the necessary #include directives to make these companion header files and their declarations available too. Patterns matching no file or non-existing files cause the command to throw an error.

Note that patterns which are not beginning with an absolute path are interpreted relative to the directory containing the current ".critcl" file.

::critcl::api extheader ?file...?

This method is similar ::critcl::api header, in that it notifies critcl of companion header files which have to be exported together with the generated stubs headers.

The difference is that these headers will be expected to exist in the external development environment. As such they will be #included in the generated header for the package, but not copied to the package header directory. Nor are they allowed to be glob patterns, as critcl has no context, i.e directory, in which to expand such patterns.

Note that the generated headers for an exported API are included in the package like it is done when importing it somewhere else. To repeat:

The "fooDecls.h" header is included at the beginning of the C code backing the ".critcl" file, and at the beginning of all companion ".c" files. This means that the writer of these files doesn't have to write the necessary #include directory, critcl does it for them.

In mode "compile & run" the generated header files, and their companion headers, if any, are placed in the subdirectory "foo" of the Result Cache. As this location is implicitly added to the include search path any other package importing this API and and build in mode "compile & run" as well will find the these headers.

For mode "generate package" the application was extended with a new option -includedir which specifies the location to place the generated headers in (again in subdirectory "foo" of that path). This path is also be added to the include search paths, ensuring that a package importing an API will find it if the package exporting that API used the same setting for -includedir.

For mode "generate TEA" the static scanner was extended to recognize critcl::api header as a source of companion files. It further uses data about critcl::api import commands to put proper support for --with-foo-include options into the generate "configure(.in)" so that a user may specify custom locations for the headers of any imported API.

PACKAGE META DATA¶

While, from the package developer's perspective, some meta data support was already present in critcl v2, through the command ::critcl::license, this was only used to generate and place a file "license.txt" into the built package.

Now critcl supports the declaration of arbitrary meta data, which will be placed into a file "teapot.txt" in a format suitable for use by the TEApot tools [http://docs.activestate.com/activetcl/8.5/tpm/toc.html].

::critcl::license author ?text...?

This command provides information about the author of the package, and its license.

If no text is present the command expects to find a file "license.terms" in the same directory as the ".critcl" file and reads the license from that. Otherwise the license is the joined texts.

This information, the license, is ignored in mode "compile & run", only mode "generate package" uses it. In that case the information is written to a file "license.terms", a sibling to the "pkgIndex.tcl" file in the directory hierarchy of the generated package.

This information is additionally placed into the meta data file "teapot.txt", under the keys as::author and license.

The data specified by this command has priority over any information specified through the generic API ::critcl::meta.

::critcl::summary text

Declares a short (one line is recommended) description of the package.

This information is ignored in mode "compile & run", only mode "generate package" uses it. In that case the information is placed into the meta data file "teapot.txt", under the key summary.

The data specified by this command has priority over any information specified through the generic API ::critcl::meta.

::critcl::description text

Declares a longer description of the package.

This information is ignored in mode "compile & run", only mode "generate package" uses it. In that case the information is placed into the meta data file "teapot.txt", under the key description.

The data specified by this command has priority over any information specified through the generic API ::critcl::meta.

::critcl::subject ?key...?

Declares one or more keywords and key-phrases describing the package, for an index.

Multiple calls of this command accumulate keywords and phrases.

This information is ignored in mode "compile & run", only mode "generate package" uses it. In that case the information is placed into the meta data file "teapot.txt", under the key subject.

The data specified by this command has priority over any information specified through the generic API ::critcl::meta.

::critcl::meta key ?word...?

This command is for the declaration of arbitrary meta data outside of the reserved keys as::author, as::build::date, description, license, name, platform, require subject, summary, and version, Its behaviour is like ::critcl::subject, in that it treats all keys as list of words, with each call declaring one or more words for the key, and multiple calls extending the data for an existing key, if not reserved.

While it is possible to declare information for one of the reserved keys with this command such data is ignored when the final meta data is assembled and written.

Use the commands ::critcl::license, ::critcl::summary, ::critcl::description ::critcl::subject, package require, and package provide to declare data for the reserved keys.

The information for the reserved keys as::build::date and platform is automatically generated by critcl itself.

::critcl::meta? key

This command enables the retrieval of meta data information from with the code defining a critcl based package. Given the key the associated value is returned as the result of the command.

The envisioned main use is the retrieval of the package's name from within utility packages having to adapt C code templates to their environment. An example of a package using this command for exactly this purpose is critcl::class.

::critcl::buildrequirement script

This command provides control over the capturing of dependencies declared via package require. It runs the script, and any dependencies declared within are ignored, i.e. not recorded in the meta data.

CONTROL & INTERFACE¶

In important thing to note about all these commands is that the package manages their information on a per-file basis. I.e. information provided by and in a file "FOO.tcl" is kept separate from the information provided by and in a file "BAR.tcl", preventing them from interfering with each other.

The commands are:

::critcl::cheaders ?arg...?

This command provides the compile step with additional header files and header locations.

All arguments matching the glob pattern -* are forwarded to the compiler's command line when it is invoked for the current ".critcl" file.

All other arguments are interpreted as glob pattern and the matching files are made available to the compiler when it is invoked for the current ".critcl" file. Patterns matching no file or non-existing files cause the command to throw an error.

Note that patterns which are not beginning with an absolute path are interpreted relative to the directory containing the current ".critcl" file.

Note further that this declaration does not cause the specified header files to be automatically #include'd. Inclusion still has to be done via either critcl::include or critcl::ccode, where necessary. It does simply ensure that the compiler will be able to find these files when invoked, by providing the necessary command line flags to extend the compiler's search paths.

Multiple invocations of this command accumulate their information.

::critcl::csources ?pattern...?

This command provides the compile step with additional C source files.

All arguments are interpreted as glob patterns. Patterns matching no file or non-existing files cause the command to throw an error. The files matching the patterns are made available to the compiler when it is invoked for the current ".critcl" file. This means that the files in question are compiled together with the ".c" file backing the ".critcl" file into a single object.

Note that patterns which are not beginning with an absolute path are interpreted relative to the directory containing the current ".critcl" file.

Multiple invocations of this command accumulate their information.

::critcl::clibraries ?arg...?

This command provides the link step with additional libraries to link and library locations.

All arguments matching the glob pattern -* are forwarded to the linkers's command line when it is invoked for the current ".critcl" file.

All other arguments are interpreted glob patterns. Patterns matching no file or non-existing files cause the command to throw an error. The files matching the patterns are made available to the linker when it is invoked for the current ".critcl" file. This means that the files in question are linked together with the object file backing the ".critcl" file into a single shared library.

Note that patterns which are not beginning with an absolute path are interpreted relative to the directory containing the current ".critcl" file.

Multiple invocations of this command accumulate their information.

::critcl::source path

This command evaluates the critcl commands in the file specified by path in the context of the current ".critcl" file.

The argument is actually considered as glob pattern and all matching files are evaluated. A pattern matching no file or non-existing files cause the command to throw an error.

Note that a pattern not beginning with an absolute path is interpreted relative to the directory containing the current ".critcl" file.

::critcl::tsources pattern...

This command provides the critcl package with information about additional Tcl script files to source when the shared library is loaded.

All arguments are considered as glob patterns and the matching files are made available to generated shared library when it is loaded for the current ".critcl" file. Patterns matching no file or non-existing files cause the command to throw an error.

Note that patterns which are not beginning with an absolute path are interpreted relative to the directory containing the current ".critcl" file.

Multiple invocations of this command accumulate their information.

The declared files are sourced after the shared library has been loaded, in the same order they were provided to critcl::tsources.

::critcl::owns pattern...

This command is ignored by the regular build modes, i.e. both "compile and run", and "generate package". It is present to support the static code scanner of critcl v3's new mode to "generate TEA" packages.

In that situation it provides the critcl package with information about any files which have to be wrapped and could not be figured out from the previous commands (i.e. critcl::csources, critcl::tsources) because of getting specified dynamically, or getting directly sourced and this not visible to critcl in any other way.

::critcl::cflags ?arg...?

This command provides the compile step with additional compiler flags.

All arguments are forwarded to the compiler's command line when it is invoked for the current ".critcl" file.

Multiple invocations of this command accumulate their information.

::critcl::ldflags ?arg...?

This command provides the link step with additional linker flags.

All arguments are forwarded to the linkers's command line when it is invoked for the current ".critcl" file.

Multiple invocations of this command accumulate their information.

::critcl::framework ?arg...?

This command provides the link step with the names of additional frameworks to link on MacOS X. The command is ignored if we are not building for OS X. This means that it is possible to declare the OS X specific frameworks unconditionally. The package itself takes care to not use them when building for non-OS X platforms.

All arguments are forwarded to the linkers's command line when it is invoked for the current ".critcl" file.

Multiple invocations of this command accumulate their information.

::critcl::tcl version

This command tells critcl for what minimum version of the Tcl runtime to compile and link the package for. If not specified critcl falls back to the default of 8.4.

::critcl::tk

This command informs critcl that the package in question is based on Tk, and therefore needs the Tk headers for compilation, and the Tk stubs for linking.

::critcl::preload lib...

This command arranges that the named dependent external shared library is loaded before the generated package's shared library.

Multiple invocations of this command accumulate their information.

Each library FOO named for preload will be searched at the locations listed below, in the order listed, and the search will stop on the first existing path. Additional notes:

And now the paths, depending on the exact form of the library name:

If you are a developer wishing to understand or modify the internals of the critcl package then you possibly should read the section explaining how the Preloading functionality is implemented.

::critcl::debug area...

This tells critcl if the package is to be compiled for debugging, and which areas to activate. Internally each area is translated into area-specific flags for the compiler which are then handed over to critcl::cflags.

INTROSPECTION¶

::critcl::check ?label? text

This command is useful to test if some functionality is available in the build environment, and then select other C code fragments based on that information. It immediately compiles the C code in text and returns a boolean value based on the result of the compilation. The command returns true on success, and false otherwise. If specified, the label is used to uniquely mark the check in the generated log.

::critcl::checklink ?label? text

This command is an extenson of critcl::check above, useful to test if some functionality is available in the build environment, and then select other C code fragments based on that information. It immediately compiles and links the C code in text and returns a boolean value based on the result of compilation and linking. The command returns true on success, and false otherwise. If specified, the label is used to uniquely mark the check in the generated log.

::critcl::msg ?-nonewline? msg

This command can be used by critc-based code to report results from critcl::check and critcl::checklink. The default implementation used by mode compile & run ignores any calls.

Tools like the CriTcl Application are allowed to redefine this procedure to perform their own way of message reporting. The package critcl::app and the application on top print such messages to stdout, for example.

::critcl::print ?-nonewline? ?chan? msg

This command is used by the critcl internals to report its activity. Its signature is equivalent to the Tcl builtin command ::puts. The default implementation is effectively ::puts.

Tools directly using either the critcl package, or the critcl application package are allowed to redefine this procedure to perform their own way of printing.

An example of this is Kettle [https://chiselapp.com/user/andreas_kupries/repository/Kettle/index] where the newest revisions use this to highlight build warnings.

::critcl::compiled

This command returns a boolean value. It returns true if the C code of the current ".critcl" file is already compiled, and false otherwise.

This predicate effectively enables a ".critcl" file used as its own Tcl companion file (see critcl::tsources) to distinguish between sourced by mode "compile & run" for compilation and sourced from either the result of mode "generate package" or during the load phase of "compile & run". In case of the two latter possibilities the result is true, and false for the first.

::critcl::compiling

This command returns a boolean value. It returns true if C code can be compiled on this platform in general, i.e. if a C compiler is available, and false otherwise.

::critcl::done

This command returns a boolean value. It returns true when critcl has built the embedded C code, and false otherwise.

This enables the Tcl code of a critcl-based package to distinguish between it getting used as a prebuilt package, versus dynamic compile & run, and take action based on that.

Note that this command is only useful from within a ".critcl" file. The result is managed on a per-file basis, like is done for the commands embedding C code and controlling the behaviour of compiler and linker.

See also section Modes Of Operation/Use.

::critcl::failed

This command returns a boolean value. It returns true if critcl has failed to build the package, and false otherwise, i.e. success. As part of this it forces the building of the package, but not its loading. Note that it will attempt to build the package only on the first call; future calls for the same package will return a cached result.

This enables a critcl-based package to check itself for availability and throw an error if it could not be built. Note that the command does not throw such an error itself.

Note further that this command is only useful from within in a ".critcl" file. The result is managed on a per-file basis, like is done for the commands embedding C code and controlling the behaviour of compiler and linker.

::critcl::load

This command is like critcl::failed, except that it also forces the loading of the generated shared library, if it was built, and that its result has reversed sense.

It returns true if critcl succeeded in building and loading the package, and false otherwise, i.e. build- or load-failure.

This enables a critcl-based package to to not only check itself for availability and throw an error if it could not be built, but also force an immediate load, circumventing the default behaviour, which is lazy. See also section Runtime Behaviour. Note that the command does not throw any error itself.

Note further that this command is only useful from within in a ".critcl" file. The result is managed on a per-file basis, like is done for the commands embedding C code and controlling the behaviour of compiler and linker.

BUILD MANAGEMENT¶

It is expected that this command is irrelevant to anybody just wishing to write a ".critcl" file. It is a management command which is only useful to the CriTcl Application or similar tools.

::critcl::config option ?val?

This command sets and returns critcl's global configuration options. These are

RESULT CACHE MANAGEMENT¶

NOTE that these commands are irrelevant to anybody just wishing to write a package using critcl for the C parts. They are management commands which are only useful to the CriTcl Application or similar tools.

::critcl::cache ?path?

This command sets and returns the path to the directory for the package's result cache.

The default location is "~/.critcl/[platform::generic]" and usually does not require any changes.

::critcl::clean_cache ?pattern...?

This command cleans the result cache, i.e. removes any and all files and directories in it. If one or more patterns are specified then only the files and directories matching them are removed.

BUILD CONFIGURATION¶

NOTE that these commands are irrelevant to anybody just wishing to write a package using critcl for the C parts. They are management commands which are only useful to the CriTcl Application or similar tools.

::critcl::readconfig path

This command reads the build configuration file at path and configures the package using the information for the currently set target platform.

::critcl::showconfig ?chan?

This command converts the currently active build configuration into a human-readable string and prints the result to the channel chan. If chan is not present the string is instead returned as the result of the command.

::critcl::showallconfig ?chan?

This command converts the set of all known build configurations (from the currently active build configuration file last set with critcl::readconfig) into a string and print the result to the channel chan. If chan is not present the string is instead returned as the result of the command.

::critcl::chooseconfig target ?nomatcherr?

This command takes a target identifier and matches it against all known targets, returning a list containing all the matching ones. This search is first done on an exact basis, and then via glob matching. If no known target matches the argument the default is to return an empty list. However, if the boolean nomatcherr is specified and set, and error will be thrown instead, using critcl::error.

::critcl::setconfig target

This command takes a target identifier and configures the package to use all its settings.

TOOL API¶

::critcl::actualtarget

This command returns the platform identifier of the target platform, i.e. the platform the generated code will be built for. In contrast to ::critcl::targetplatform this is the true target, with any cross-compilation information resolved.

::critcl::buildforpackage ?flag?

This command signals whether the next file to be build is built for inclusion into a package or not. If not specified the flag defaults to true, i.e. building for a package. This disables a number of things in the backend, namely the linking of that file into a shared library, and loading such. It is expected that the build results are later wrapped into a larger collection.

::critcl::cnothingtodo file

This command checks whether there is anything to build for file.

::critcl::cresults ?file?

This command returns the build result information for the specified file. If no file is specified the information is taken from info script. The result in question is a Tcl dictionary with the following keys, and their meanings:

::critcl::crosscheck

This command checks if the package is configured for cross-compilation and prints a message to the standard error channel if so.

::critcl::error msg

This command is used by the package to report internal errors. The default implementation simply throws the error. Tools like the CriTcl Application are allowed to redefine this procedure to perform their own way of error reporting. There is one constraint they are not allowed to change: The procedure must not return to the caller.

::critcl::knowntargets

This command returns a list containing the identifiers of all targets found during the last invocation of critcl::readconfig.

::critcl::sharedlibext

This command returns the file extension used by shared libraries on the target platform.

::critcl::targetconfig

This command returns the target identifier chosen to by either system or user to build code for.

::critcl::buildplatform

This command returns the platform identifier of the build platform, i.e. where the package is running on.

::critcl::targetplatform

This command returns the platform identifier of the target platform, i.e. the platform the generated code will be built for. In contrast to ::critcl::actualtarget this may be the name of a cross-compilation target.

::critcl::cobjects ?arg...?

This command is like ::critcl::clibraries, provides the link step with additional information. Instead of libraries the arguments are object files however. Despite this similarity it is not listed in section Control & Interface because it is of no use to package writers. Only tools like the CriTcl Application have need of it.

All arguments are interpreted glob patterns. Patterns matching no file or non-existing files cause the command to throw an error. The files matching the patterns are made available to the linker when it is invoked for the current ".critcl" file. This means that the files in question are linked together with the object file backing the ".critcl" file into a single shared library.

Note that patterns which are not beginning with an absolute path are interpreted relative to the directory containing the current ".critcl" file.

Multiple invocations of this command accumulate their information.

::critcl::scan path

This command is the main entry point to critcl's static code scanner. Invoked for a single ".critcl" file it returns a dictionary providing the following pieces information about it:

This command and the information it returns can be used by tools to implement processing modes like the assembly of a directory hierarchy containing a TEA-lookalike buildystem, etc.

::critcl::name2c name

This command exposes the conversion of a Tcl level identifier of commands into various C-level pieces, i.e. Tcl namespace prefix, C namespace prefix, Tcl base name, and C base name.

The result of the command is a list of 4 elements providing the above mentioned information, in the named order.

The envisioned main use is from within utility packages providing Tcl commands without going through the standard commands, i.e. critcl::ccommand, or critcl::cproc. An example of a package using this command for exactly this purpose is critcl::class.

ADVANCED: EMBEDDED C CODE¶

::critcl::argnames arguments

This command takes an argument declaration as taken by critcl::cproc and returns a list of the user visible arguments found in the declaration.

::critcl::argcnames arguments

This command takes an argument declaration as taken by critcl::cproc and returns a list of the C side variable names for the user visible arguments found in the declaration. The names returned here match the names used in the declarations and code returned by ::critcl::argvardecls and ::critcl::argconversion.

::critcl::argcsignature arguments

This command takes an argument declaration as taken by critcl::cproc and returns a list of C parameter declarations for all arguments found in the declaration.

::critcl::argvardecls arguments

This command takes an argument declaration as taken by critcl::cproc and returns a list of C side variable declarations for the user visible arguments found in the declaration. The names used in these declarations match the names returned by ::critcl::argcnames.

::critcl::argconversion arguments ?n?

This command takes an argument declaration as taken by critcl::cproc and returns a list of C code fragments converting the user visible arguments found in the declaration from Tcl_Obj* to C types. The names used in these statements match the names returned by ::critcl::argcnames.

The generated code assumes that the procedure arguments start at index n of the objv array. If this argument is not specified 1 will be assumed.

::critcl::argoptional arguments

This command takes an argument declaration as taken by critcl::cproc and returns a list of boolean values indicating which arguments are optional (true) and not (false).

::critcl::argdefaults arguments

This command takes an argument declaration as taken by critcl::cproc and returns a list containing the default values for all optional arguments.

::critcl::argsupport arguments

This command takes an argument declaration as taken by critcl::cproc and returns a list of C code fragments needed to define the necessary supporting types.

CUSTOM BUILD CONFIGURATION¶

::critcl::userconfig define name description type ?default?

This command defines custom build configuration option, with description, type and optional default value.

The type can be either bool, or a list of values.

The description serves as in-code documentation of the meaning of the option and is otherwise ignored. When generating a TEA wrapper the description is used for the configure option derived from the option declared by the command.

A boolean option FOO are translated into a pair of configure options, --enable-FOO and --disable-FOO, whereas an option whose type is a list of values is translated into a single configure option --with-FOO.

::critcl::userconfig query name

This command queries the database of custom build configuration option for the current ".critcl" file and returns the chosen value. This may be the default if no value was set via ::critcl::userconfig set.

It is at this point that definitions and set values are brought together, with the latter validated against the definition.

::critcl::userconfig set name value

This command is for use by a tool, like the critcl application, to specify values for custom build configuration options.

At the time this command is used only the association between option name and value is recorded, and nothing else is done. This behaviour is necessary as the system may not know if an option of the specified name exists when the command is invoked, nor its type.

Any and all validation is defered to when the value of an option is asked for via ::critcl::userconfig query.

This means that it is possible to set values for any option we like, and the value will take effect only if such an option is both defined and used later on.

ADVANCED: LOCATION MANAGEMENT¶

By default critcl embeds #line directives into the generated C code so that any errors, warnings and notes found by the C compiler during compilation will refer to the ".critcl" file the faulty code comes from, instead of the generated ".c" file.

Side note: This facility requires the use of a tclsh supporting the builtin info frame command. If critcl is run by a tclsh not supporting this no #line directives will be emitted. The command is supported by Tcl 8.5 and higher. It is also supported by Tcl 8.4 provided that it was compiled with the define -DTCL_TIP280. An example of such is ActiveState's ActiveTcl.

Most users will not care about this feature beyond simply wanting it to work and getting proper code references when reading compiler output.

Developers of higher-level packages generating their own C code however should care about this, to ensure that their generated code contains proper references as well. Especially as this is key to separating bugs concerning code generated by the package itself and bug in the user's code going into the package, if any.

Examples of such packages come with critcl itself, see the implementation of packages critcl::iassoc and critcl::class.

To help such developers eight commands are provided to manage such location information. These are listed below.

A main concept is that they all operate on a single stored location, setting, returning and clearing it. Note that this location information is completely independent of the generation of #line directives within critcl itself.

::critcl::at::caller

This command stores the location of the caller of the current procedure as a tuple of file name and linenumber. Any previously stored location is overwritten. The result of the command is the empty string.

::critcl::at::caller offset

As above, the stored line number is modified by the specified offset. In essence an implicit call of critcl::at::incr.

::critcl::at::caller offset level

As above, but the level the location information is taken from is modified as well. Level 0 is the caller, -1 its caller, etc.

::critcl::at::here

This command stores the current location in the current procedure as a tuple of file name and linenumber. Any previously stored location is overwritten. The result of the command is the empty string.

In terms of ::critcl::at::caller this is equivalent to

	critcl::at::caller 0 1

::critcl::at::get*

This command takes the stored location and returns a formatted #line directive ready for embedding into some C code. The stored location is left untouched. Note that the directive contains its own closing newline.

For proper nesting and use it is recommended that such directives are always added to the beginning of a code fragment. This way, should deeper layers add their own directives these will come before ours and thus be inactive. End result is that the outermost layer generating a directive will 'win', i.e. have its directive used. As it should be.

::critcl::at::get

This command is like the above, except that it also clears the stored location.

::critcl::at::= file line

This command allows the caller to set the stored location to anything they want, outside of critcl's control. The result of the command is the empty string.

::critcl::at::incr n...

::critcl::at::incrt str...

These commands allow the user to modify the line number of the stored location, changing it incrementally. The increment is specified as either a series of integer numbers (incr), or a series of strings to consider (incrt). In case of the latter the delta is the number of lines endings found in the strings.

::critcl::at::caller!

::critcl::at::caller! offset

::critcl::at::caller! offset level

::critcl::at::here!

These are convenience commands combining caller and here with get. I.e. they store the location and immediately return it formatted as proper #line directive. Also note that after their use the stored location is cleared.

ADVANCED: DIVERSIONS¶

These commands normally generate all of their C code for the current ".critcl" file, which may not be what is wanted by a higher-level package.

With a diversion the generator output can be redirected into memory and from there on then handled and processed as the caller desires before it is committed to an actual ".c" file.

An example of such a package comes with critcl itself, see the implementation of package critcl::class.

To help such developers three commands are provided to manage diversions and the collection of C code in memory. These are:

::critcl::collect_begin

This command starts the diversion of C code collection into memory.

The result of the command is the empty string.

Multiple calls are allowed, with each call opening a new nesting level of diversion.

::critcl::collect_end

This command end the diversion of C code collection into memory and returns the collected C code.

If multiple levels of diversion are open the call only closes and returns the data from the last level.

The command will throw an error if no diversion is active, indicating a mismatch in the pairing of collect_begin and collect_end.

::critcl::collect script

This is a convenience command which runs the script under diversion and returns the collected C code, ensuring the correct pairing of collect_begin and collect_end.

ADVANCED: FILE GENERATION¶

Three examples of utility packages using this facility comes with critcl itself. See the implementations of packages critcl::literals, critcl::bitmap, and critcl::enum.

When splitting a package implementation into pieces it is often sensible to have a number of pure C companion files containing low-level code, yet these files may require information about the code in the main ".critcl" file. Such declarations are normally not exportable and using the stub table support does not make sense, as this is completely internal to the package.

With the file generation command below the main ".critcl" file can generate any number of header files for the C companions to pick up.

::critcl::make path contents

This command creates the file path in a location where the C companion files of the package are able to pick it up by simple inclusion of path during their compilation, without interfering with the outer system at all.

The generated file will contain the specified contents.

ADVANCED: EXTENDING CPROC¶

To get around this limitation the commands in this section enable users of critcl to extend the set of argument and result types understood by critcl::cproc. In other words, they allow them to define their own, custom, types.

::critcl::has-resulttype name

This command tests if the named result-type is known or not. It returns a boolean value, true if the type is known and false otherwise.

::critcl::resulttype name body ?ctype?

This command defines the result type name, and associates it with the C code doing the conversion (body) from C to Tcl. The C return type of the associated function, also the C type of the result variable, is ctype. This type defaults to name if it is not specified.

If name is declared already an error will be thrown. Attention! The standard result type void is special as it has no accompanying result variable. This cannot be expressed by this extension command.

The body's responsibility is the conversion of the functions result into a Tcl result and a Tcl status. The first has to be set into the interpreter we are in, and the second has to be returned.

The C code of body is guaranteed to be called last in the wrapper around the actual implementation of the cproc in question and has access to the following environment:

As examples here are the definitions of two standard result types:

    resulttype int {
	Tcl_SetObjResult(interp, Tcl_NewIntObj(rv));
	return TCL_OK;
    }
    resulttype ok {
	/* interp result must be set by cproc body */
	return rv;
    } int

::critcl::resulttype name = origname

This form of the resulttype command declares name as an alias of result type origname, which has to be defined already. If this is not the case an error is thrown.

::critcl::has-argtype name

This command tests if the named argument-type is known or not. It returns a boolean value, true if the type is known and false otherwise.

::critcl::argtype name body ?ctype? ?ctypefun?

This command defines the argument type name, and associates it with the C code doing the conversion (body) from Tcl to C The C type of the variable to hold the conversion result is ctype and the type of the function argument itself is ctypefun. Both types default to name if they are not specified (or the empty string).

If name is declared already an error will be thrown.

The body's responsibility is the conversion of a command's Tcl_Obj* argument into a C value for the underlying function and its storage in a helper variable.

The C code of body is guaranteed to be called inside of a separate C code block (thus allowing the use of local variables) which has access to the following environment:

As examples here are the definitions of two standard argument types:

    argtype int {
	if (Tcl_GetIntFromObj(interp, @@, &@A) != TCL_OK) return TCL_ERROR;
    }
    argtype float {
	double t;
	if (Tcl_GetDoubleFromObj(interp, @@, &t) != TCL_OK) return TCL_ERROR;
	@A = (float) t;
    }

::critcl::argtype name = origname

This form of the argtype command declares name as an alias of argument type origname, which has to be defined already. If this is not the case an error is thrown.

::critcl::argtypesupport name code ?guard?

This command defines a C code fragment for the already defined argument type name which will be inserted before all functions using that type. Its purpose is the definition of any supporting C types needed by the argument type. If the type is used by many functions the system ensures that only the first of the multiple insertions of the code fragment is active, and the others disabled. The guard identifier is normally derived from name, but can also be set explicitly, via guard. This latter allows different custom types to share a common support structure without having to perform their own guarding.

::critcl::argtyperelease name code

This command defines a C code fragment for the already defined argument type name which will be inserted whenever the worker function of a critcl::cproc returns to the shim. It is the responsibility of this fragment to unconditionally release any resources the critcl::argtype conversion code allocated. An example of this are the variadic types for the support of the special, variadic args argument to critcl::cproc's. They allocate a C array for the collected arguments which has to be released when the worker returns. This command defines the C code for doing that.

MODES OF OPERATION/USE¶

[1]

Compile & Run, and

[2]

Generate Package

[3]

Generate TEA Package

Of these three Compile & Run came first and is the default when using the package directly. In that case the package collects the C fragments, builds them as needed, and caches the results for quick reuse when the same code is used in the future again.

The second mode, Generate Package, was introduced to enable the creation of (prebuilt) deliverable packages which do not depend on the existence of a build system, i.e. C compiler, on the target machine. This was originally done through the experimental Critbind tool, and is now handled by the CriTcl Application, also named critcl.

Newly introduced with Critcl version 3 is Generate TEA Package. This mode constructs a directory hierarchy from the package which can later be built like a regular TEA package, i.e. using

	.../configure --prefix ...
	make all isntall

Regarding the caching of results please read the section about the Result Cache fore more details.

RUNTIME BEHAVIOUR¶

A limitation of this behaviour is that it is not possible to just use info commands check for the existence of a critcl defined command. It is also necessary to search in the auto_index array, in case it has not been build yet.

This behaviour can be changed by using the control command critcl::load. When invoked, the building, including loading of the result, is forced. After this command has been invoked for a ".critcl" file further definition of C code in this file is not allowed any longer.

FILE MAPPING¶

The Embedded C Code fragments appear in that file in the exact same order they were defined in the ".critcl" file, with one exception. The C code provided via critcl::cinit is put after all other fragments. In other words all fragments have access to the symbols defined by earlier fragments, and the critcl::cinit fragment has access to all, regardless of its placement in the ".critcl" file.

Note: A limitation of the current system is the near impossibility of C level access between different critcl-based packages. The issue is not the necessity of writing and sharing the proper extern statements, but that the management (export and import) of package-specific stubs-tables is not supported. This means that dependent parts have to be forcibly loaded before their user, with all that entails. See section Runtime Behaviour for the relevant critcl limitation, and remember that many older platforms do not support the necessary resolution of symbols, the reason why stubs were invented for Tcl in the first place.

RESULT CACHE¶

This means that on the first use of a ".critcl" file "FOO.tcl" the resulting object file and shared library are saved into the cache, and on future uses of the same file reused, i.e. loaded directly without requiring compilation, provided that the contents of "FOO.tcl" did not change.

The change detection is based MD5 hashes. A single hash is computed for each ".critcl" file, based on hashes for all C code fragments and configuration options, i.e. everything which affects the resulting binary.

As long as the input file doesn't change as per the hash a previously built shared library found in the cache is reused, bypassing the compilation and link stages.

The command to manage the cache are found in section Result Cache Management. Note however that they are useful only to tools based on the package, like the CriTcl Application. Package writers have no need of them.

As a last note, the default directory for the cache is chosen based on the chosen build target. This means that the cache can be put on a shared (network) filesystem without having to fear interference between machines of different architectures.

PRELOADING FUNCTIONALITY¶

It explains how the preloading of external libraries is realized.

Whenever a package declares libraries for preloading critcl will build a supporting shared library providing a Tcl package named "preload". This package is not distributed separately, but as part of the package requiring the preload functionality. This support package exports a single Tcl command

::preload library

which is invoked once per libraries to preload, with the absolute path of that library. The command then loads the library.

On windows the command will further use the Tcl command ::critcl::runtime::precopy to copy the library to the disk, should its path be in a virtual filesystem which doesn't directly support the loading of a shared library from it.

The command ::critcl::runtime::precopy is provided by the file "critcl-rt.tcl" in the generated package, as is the command ::critcl::runtime::loadlib which generates the ifneeded script expected by Tcl's package management. This generated ifneeded script contains the invocations of ::preload.

The C code for the supporting library is found in the file "critcl_c/preload.c", which is part of the critcl package.

The Tcl code for the supporting runtime "critcl-rt.tcl" is found in the file "runtime.tcl", which is part of the critcl::app package.

CONFIGURATION INTERNALS¶

It explains the syntax of configuration files and the configuration keys used by critcl to configure its build backend, i.e. how this part of the system accesses compiler, linker, etc.

It is recommended to open the file containing the standard configurations ("path/to/critcl/Config") in the editor of your choice when reading this section of the documentation, using it as an extended set of examples going beyond the simple defaults shown here.

First, the keys and the meaning of their values, plus examples drawn from the standard configurations distributed with the package. Note that when writing a custom configuration it is not necessary to specify all the keys listed below, but only those whose default values are wrong or insufficient for the platform in question.

version

The command to print the compiler version number. Defaults to

 gcc -v

compile

The command to compile a single C source file to an object file. Defaults to

 gcc -c -fPIC

debug_memory

The list of flags for the compiler to enable memory debugging in Tcl. Defaults to

 -DTCL_MEM_DEBUG

debug_symbols

The list of flags for the compiler to add symbols to the object files and the resulting library. Defaults to

 -g

include

The compiler flag to add an include directory. Defaults to

 -I

tclstubs

The compiler flag to set USE_TCL_STUBS. Defaults to

 -DUSE_TCL_STUBS

tkstubs

The compiler flag to set USE_TK_STUBS. Defaults to

 -DUSE_TK_STUBS

threadflags

The list of compiler flags to enable a threaded build. Defaults to

    -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1
    -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1 -DHAVE_READDIR_R=1
    -DTCL_THREADS=1

.

noassert

The compiler flag to turn off assertions in Tcl code. Defaults to

 -DNDEBUG

optimize

The compiler flag to specify optimization level. Defaults to

 -O2

output

The compiler flags to set the output file of a compilation. Defaults to

 -o [list $outfile]

NOTE the use of Tcl commands and variables here. At the time critcl uses the value of this key the value of the referenced variable is substituted into it. The named variable is the only variable whose value is defined for this substitution.

object

The file extension for object files on the platform. Defaults to

 .o

preproc_define

The command to preprocess a C source file without compiling it, but leaving #define's in the output. Defaults to

 gcc -E -dM

preproc_enum

See preproc_define, except that #define's are not left in the output. Defaults to

 gcc -E

link

The command to link one or more object files and create a shared library. Defaults to

 gcc -shared

link_preload

The list of linker flags to use when dependent libraries are pre-loaded. Defaults to

 --unresolved-symbols=ignore-in-shared-libs

strip

The flag to tell the linker to strip symbols from the shared library. Defaults to

 -Wl,-s

ldoutput

Like output, but for the linker. Defaults to the value of output.

link_debug

The list of linker flags needed to build a shared library with symbols. Defaults to the empty string. One platform requiring this are all variants of Windows, which uses

 -debug:full -debugtype:cv

link_release

The list of linker flags needed to build a shared library without symbols, i.e. a regular build. Defaults to the empty string. One platform requiring this are all variants of Windows, which uses

 -release -opt:ref -opt:icf,3 -ws:aggressive

sharedlibext

The file extension for shared library files on the platform. Defaults to

 [info sharedlibextension]

platform

The identifier of the platform used in generated packages. Defaults to

 [platform::generic]

target

The presence of this key marks the configuration as a cross-compilation target and the value is the actual platform identifier of the target. No default.

The syntax expected from configuration files is governed by the rules below. Again, it is recommended to open the file containing the standard configurations ("path/to/critcl/Config") in the editor of your choice when reading this section of the documentation, using it as an extended set of examples for the syntax>

[1]

Each logical line of the configuration file consists of one or more physical lines. In case of the latter the physical lines have to follow each other and all but the first must be marked by a trailing backslash. This is the same marker for continuation lines as used by Tcl itself.

[2]

A (logical) line starting with the character "#" (modulo whitespace) is a comment which runs until the end of the line, and is otherwise ignored.

[3]

A (logical) line starting with the word "if" (modulo whitespace) is interpreted as Tcl's if command and executed as such. I.e. this command has to follow Tcl's syntax for the command, which may stretch across multiple logical lines. The command will be run in a save interpreter.

[4]

A (logical) line starting with the word "set" (modulo whitespace) is interpreted as Tcl's set command and executed as such. I.e. this command has to follow Tcl's syntax for the command, which may stretch across multiple logical lines. The command will be run in a save interpreter.

[5]

A line of the form "platform variable value" defines a platform specific configuration variable and value. The variable has to be the name of one of the configuration keys listed earlier in this section, and the platform string identifies the platform the setting is for. All settings with the same identification string form the configuration block for this platform.

[6]

A line of the special form "platform when expression" marks the platform and all the settings in its configuration block as conditional on the expression.

If the build platform is not a prefix of platform, nor vice versa the whole block is ignored. Otherwise the expression is evaluated via expr, in the same safe interpreter used to run any set and if commands found in the configuration file (see above).

If the expression evaluates to true this configuration block is considered to be the build platform fo the host and chosen as the default configuration. An large example of of this feature is the handling of OS X found in the standard configuration file, where it selects the architectures to build based on the version of the operating system, the available SDK, etc. I.e. it chooses whether the output is universal or not, and whether it is old-style (ix86 + ppc) versus new-style (ix86 32+64) of universality.

[7]

A line of the special form "platform copy sourceplatform" copies the configuration variables and values currently defined in the configuration block for sourceplatform to that of platform, overwriting existing values, and creating missing ones. Variables of platform not defined by by sourceplatform are not touched.

The copied values can be overridden later in the configuration file. Multiple copy lines may exist for a platform and be intermixed with normal configuration definitions. If a variable is defined multiple times, the last definition will be used.

[8]

At last, a line of the form "variable value" defines a default configuration variable and value.

STUBS TABLES This section is for developers of extensions not based on critcl, yet¶

To this end we describe the stubs table information of a package foo.

[1]

Note that the differences in the capitalization of "foo", "Foo", "FOO", etc. below demonstrate how to capitalize the actual package name in each context.

[2]

All relevant files must be available in a sub-directory "foo" which can be found on the include search paths.

[3]

The above directory may contain a file "foo.decls". If present it is assumed to contain the external representation of the stubs table the headers mentioned in the following items are based on.

critcl is able to use such a file to give the importing package programmatic access to the imported API, for automatic code generation and the like.

[4]

The above directory must contain a header file "fooDecls.h". This file declares the exported API. It is used by both exporting and importing packages. It is usually generated and must contain (in the order specified):

A very reduced, yet also complete example, from a package for low-level random number generator functions can be found at the end of this section.

[5]

The above directory must contain a header file "fooStubLib.h". This file defines everything needed to use the API of foo. Consequently it is used only by importing packages. It is usually generated and must contain (in the order specified):

const FooStubs* fooStubsPtr;

char *
Foo_InitStubs(Tcl_Interp *interp, CONST char *version, int exact)
{
    /*
     * Boiler plate C code initalizing the stubs table variable,
     * i.e. "fooStubsPtr".
     */
    CONST char *actualVersion;
    actualVersion = Tcl_PkgRequireEx(interp, "foo", version,
				     exact, (ClientData *) &fooStubsPtr);
    if (!actualVersion) {
	return NULL;
    }
    if (!fooStubsPtr) {
	Tcl_SetResult(interp,
		      "This implementation of Foo does not support stubs",
		      TCL_STATIC);
	return NULL;
    }
    return (char*) actualVersion;
}

This header file must be included by an importing package exactly once, so that it contains only one definition of both stubs table and stubs initializer function.

The importing package's initialization function must further contain a statement like

if (!Foo_InitStubs (ip, "1", 0)) {
    return TCL_ERROR;
}

which invokes foo's stubs initializer function to set the local stub table up.

For a complete example of such a header file see below, at the end of this section.

[6]

The last item above, about "fooStubLib.h" differs from the regular stub stable system used by Tcl. The regular system assumes that a static library "libfoostub.a" was installed by package foo, and links it.

IMVHO critcl's approach is simpler, using only header files found in a single location, vs. header files and static library found in multiple, different locations.

A second simplification is that we avoid having to extend critcl's compiler backend with settings for the creation of static libraries.

Below is a complete set of example header files, reduced, yet still complete, from a package for low-level random number generator functions:

"rngDecls.h":

#ifndef rng_DECLS_H
#define rng_DECLS_H
#include <tcl.h>
/*
 * Exported function declarations:
 */
/* 0 */
EXTERN void rng_bernoulli(double p, int*v);
typedef struct RngStubs {
    int magic;
    const struct RngStubHooks *hooks;
    void (*rng_bernoulli) (double p, int*v); /* 0 */
} RngStubs;
#ifdef __cplusplus
extern "C" {
#endif
extern const RngStubs *rngStubsPtr;
#ifdef __cplusplus
}
#endif
#if defined(USE_RNG_STUBS)
/*
 * Inline function declarations:
 */
#define rng_bernoulli  (rngStubsPtr->rng_bernoulli) /* 0 */
#endif /* defined(USE_RNG_STUBS) */
#endif /* rng_DECLS_H */

"rngStubLib.h":

/*
 * rngStubLib.c --
 *
 * Stub object that will be statically linked into extensions that wish
 * to access rng.
 */
#ifndef USE_TCL_STUBS
#define USE_TCL_STUBS
#endif
#undef  USE_TCL_STUB_PROCS
#include <tcl.h>
#ifndef USE_RNG_STUBS
#define USE_RNG_STUBS
#endif
#undef  USE_RNG_STUB_PROCS
#include "rngDecls.h"
/*
 * Ensure that Rng_InitStubs is built as an exported symbol.  The other stub
 * functions should be built as non-exported symbols.
 */
#undef  TCL_STORAGE_CLASS
#define TCL_STORAGE_CLASS DLLEXPORT
const RngStubs* rngStubsPtr;
/*
 *----------------------------------------------------------------------
 *
 * Rng_InitStubs --
 *
 * Checks that the correct version of Rng is loaded and that it
 * supports stubs. It then initialises the stub table pointers.
 *
 * Results:
 *  The actual version of Rng that satisfies the request, or
 *  NULL to indicate that an error occurred.
 *
 * Side effects:
 *  Sets the stub table pointers.
 *
 *----------------------------------------------------------------------
 */
#ifdef Rng_InitStubs
#undef Rng_InitStubs
#endif
char *
Rng_InitStubs(Tcl_Interp *interp, CONST char *version, int exact)
{
    CONST char *actualVersion;
    actualVersion = Tcl_PkgRequireEx(interp, "rng", version,
				     exact, (ClientData *) &rngStubsPtr);
    if (!actualVersion) {
	return NULL;
    }
    if (!rngStubsPtr) {
	Tcl_SetResult(interp,
		      "This implementation of Rng does not support stubs",
		      TCL_STATIC);
	return NULL;
    }
    return (char*) actualVersion;
}