A short note ahead of the documentation: Instead of repeatedly talking about "a Tcl script with embbedded
C code", or "a Tcl script containing CriTcl commands", we call such a script a CriTclscript. A file
containing a CriTclscript usually has the extension .tcl or .critcl.
EMBEDDEDCCODE
The following commands append C code fragments to the current module. Fragments appear in the module in
the order they are appended, so the earlier fragments (variables, functions, macros, etc.) are visible to
later fragments.
::critcl::ccodefragment
Appends the C code in fragment to the current module and returns the empty string. See RuntimeBehaviour.
::critcl::ccommandtclnamecname
As documented below, except that cname is the name of a C function that already exists.
::critcl::ccommandtclnameargumentsbody ?optionvalue...?
Appends the code to create a Tcl command named tclname and a corresponding C function whose body
is body and which behaves as documented for Tcl's own Tcl_CreateObjCommand [https://www.tcl-
lang.org/man/tcl/TclLib/CrtObjCmd.htm].
aguments is a list of zero to four names for the standard arguments clientdata, interp, objc, and
objv. The standard default names are used in place of any missing names. This is a more low-
level way than critcl::cproc to define a command, as processing of the items in objv is left to
the author, affording complete control over the handling of the arguments to the command. See
section RuntimeBehaviour.
Returns the empty string.
Each option may be one of:
-clientdatac-expression
Provides the client data for the new command. NULL by default.
-delprocc-expression
Provides a function pointer of type Tcl_CmdDeleteProc [https://www.tcl-
lang.org/man/tcl/TclLib/CrtObjCmd.htm] as the deletion function for the new command. NULL
by default.
-cnameboolean
If false (the default), a name for the corresponding C function is automatically derived
from the fully-qualified tclname. Otherwise, name of the C function is the last component
of tclname.
::critcl::cdatatclnamedata
Appends the code to create a new Tcl command named tclname which returns data as a ByteArray
result.
Returns the empty string.
::critcl::cconsttclnameresulttypevalue
Appends the code to create a new Tcl command named tclname which returns the constant value having
the Tcl type resulttype. value can be a C macro or a function call (including the parentheses) to
any visible C function that does not take arguments. Unlike critcl::cdata, resulttype can be any
type known to critcl::cproc. Its semantics are equivalent to:
cproc $tclname {} $resulttype "return $value ;"
This is more efficient than critcl::cproc since there is no C function generated.
Returns the empty string.
::critcl::cdefineslistofglobpatterns ?namespace?
Arranges for Cenum and #define values that match one of the patterns in globpatterns to be
created in the namespace namespace, each variable having the same as the corresponding C item.
The default namespace is the global namespace. A pattern that matches nothing is ignored.
The Tcl variables are created when the module is compiled, using the preprocessor in order to
properly find all matching C definitions.
Produces no C code. The desired C definitions must already exist.
::critcl::cprocnameargumentsresulttypebody ?optionvalue...?
Appends a function having body as its body, another shim function to perform the needed
conversions, and the code to create a corresponding Tcl command named tclname. Unlike
critcl::ccommand the arguments and result are typed, and CriTcl generates the code to convert
between Tcl_Obj values and C data types. See also RuntimeBehaviour.
Returns the empty string.
string option
Each may be one of:
-cnameboolean
If false (the default), a name for the corresponding C function is automatically
derived from the fully-qualified tclname. Otherwise, name of the C function is the
last component of tclname.
-pass-cdataboolean
If false (the default), the shim function performing the conversion to and from Tcl
level does not pass the ClientData as the first argument to the function.
-arg-offsetint
A non-negative integer, 0 by default, indicating the number of hidden arguments
preceding the actual procedure arguments. Used by higher-order code generators
where there are prefix arguments which are not directly seen by the function but
which influence argument counting and extraction.
string resulttype
May be a predefined or a custom type. See CriTclcprocTypeReference for the full list of
predefined types and how to extend them. Unless otherwise noted, the Tcl return code is
always TCL_OK.
list arguments
Is a multi-dictionary where each key is an argument type and its value is the argument
name. For example:
int x int y
Each argument name must be a valid C identifier.
If the name is a list containing two items, the first item is the name and the second item is the
default value. A limited form of variadic arguments can be accomplished using such default
values. For example:
int {x 1}
Here x is an optional argument of type int with a default value of 1.
Argument conversion is completely bypassed when the argument is not provided, so a custom
converter doing validation does not get the chance to validate the default value. In this
case, the value should be checked in the body of the function.
Each argument type may be a predefined or custom type. See CriTclcprocTypeReference for
the full list of predefined types and how to extend them.
::critcl::cprocnameargumentsresulttype
As documented below, but used when the C function named name already exists.
::critcl::cinittextexternals
Appends the C code in text and externals, but only after all the other fragments appended by the
previously-listed commands regardless of their placement in the CriTclscript relative to this
command. Thus, all their content is visible. See also RuntimeBehaviour.
The C code in text is placed into the body of the initialization function of the shared library
backing the CriTclscript, and is executed when this library is loaded into the interpreter. It
has access to the variable Tcl_Interp*interp referencing the Tcl interpreter currently being
initialized.
externals is placed outside and just before the initialization function, making it a good place
for any external symbols required by initialization function, but which should not be accessible
by any other parts of the C code.
Calls to this command are cumulative.
Returns the empty string.
::critcl::includepath
This command is a convenient shorthand for
critcl::code {
#include <${path}>
}
STUBSTABLEMANAGEMENT
CriTcl versions 3 and later provide critcl::api to create and manipulate stubs tables, Tcl's dynamic
linking mechanism handling the resolution of symbols between C extensions. See http://wiki.tcl-lang.org/285 for an introduction, and section StubsTables for the details of CriTcl's particular
variant.
Importing stubs tables, i.e. APIs, from another extension:
::critcl::apiimportnameversion
Adds the following include directives into the CriTclscriptand each of its companion ".c" files:
[1] #include <name/nameDecls.h>
[2] #include <name/nameStubLib.h>
Returns an error if "name" isn't in the search path for the compiler. See critcl::cheaders and
the critcl application's -I and -includedir options.
Important: If name is a fully-qualified name in a non-global namespace, e.g. "c::stack", the
namespace separators "::" are converted into underscores ("_") in path names, C code, etc.
name/nameDecls.h contains the stubs table type declarations, mapping macros, etc., and may include
package-specific headers. See critcl::apiheader, below. An #include directive is added at the
beginning of the generated code for CriTclscript and at the beginning of each of its companion
".c" files.
name/nameStubLib.h contains the stubs table variable definition and the function to initialize it.
An #include directive for it is added to the initialization code for the CriTclscript , along
with a call to the initializer function.
If "name/name.decls" accompanies name/nameDecls.h, it should contain 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 for use by the importing package. Otherwise, the empy string is
returned.
One possible use would be the automatic generation of C code calling on the functions listed in
the imported API.
When generating a TEA package the names of the imported APIs are used to declare configure options
with which the user can declare a non-standard directory for the headers of the API. Any API name
is translated into a single configure option --with-name-include.
Declaration and export of a stubs table, i.e. API, for the CriTclscript:
::critcl::apifunctionresulttypenamearguments
Adds to the public API of the CriTclscript the signature for the function named name and having
the signature specified by arguments and resulttype. Code is generated for a ".decls" file, the
corresponding public headers, and a stubs table usable by critcl::apiimport.
arguments is a multidict where each key is an argument type and its value is the argument name,
and resulttype is a C type.
::critcl::apiheader ?globpattern...?
Each file matching a globpattern is copied into the directory containing the generated headers,
and an #include directive for it is added to "Decls.h" for the CriTclscript. Returns an error if
a globpattern matches nothing.
A pattern for a relative path is resolved relative to the directory containing the CriTclscript.
::critcl::apiextheader ?file...?
Like ::critcl::apiheader, but each file should exist in the external development environment. An
#include directive is added to "fooDecls.h", but file is not copied to the package header
directory. file is not a glob pattern as CriTcl has no context, i.e directory, in which to expand
such patterns.
As with the headers for an imported API, an #include directive is added to the generated code for the
CriTclscript and to each companion ".c" file.
In "compile & run" mode the generated header files and any companion headers are placed in the ResultCache subdirectory for the CriTclscript. This directory is added to the include search path of any other
package importing this API and and building in mode "compile & run".
In "generate package" mode -includedir specifies the subdirectory in the package to place the generated
headers in. This directory is added to the search paths for header files, ensuring that a package
importing an API finds it if the package exporting that API used the same setting for -includedir.
In "generate TEA" mode the static scanner recognizes critcl::apiheader as a source of companion files.
It also uses data from calls to critcl::apiimport to add support for --with-foo-include options into the
generated "configure(.in)" so that a user may specify custom locations for the headers of any imported
API.
PACKAGEMETADATA
CriTcl versions 3 and later can create TEApot meta-data to be placed into "teapot.txt" in a format
suitable for use by the TEApottools [http://docs.activestate.com/activetcl/8.5/tpm/toc.html].
In version 2, some meta data support was already present through ::critcl::license, but this was only
used to generate "license.txt".
::critcl::licenseauthor ?text...?
Ignored in "compile & run" mode.
In "generate package" mode provides information about the author of the package and the license
for the package.
text arguments are concatenated to form the text of the license, which is written to
"license.terms" in the same directory as "pkgIndex.tcl". If no text is provided the license is
read from "license.terms" in the same directory as the CriTclscript.
This information takes precedence over any information specified through the generic API
::critcl::meta. It is additionally placed into the meta data file "teapot.txt" under the keys
as::author and license.
::critcl::summarytext
Ignored in "compile & run" mode.
In "generate package" mode places a short, preferably one-line description of the package into the
meta data file "teapot.txt" under the key summary. This information takes precedence over
information specified through the generic API ::critcl::meta.
::critcl::descriptiontext
Ignored in "compile & run" mode.
In "generate package" mode places a longer description of the package into the meta data file
"teapot.txt", under the key description. The data specified by this command takes precedence over
any information specified through the generic API ::critcl::meta.
::critcl::subject ?key...?
Ignored in "compile & run" mode.
In "generate package" mode places each key into the meta data file "teapot.txt", under the key
subject. This information takes precedence over any information specified through the generic API
::critcl::meta.
Calls to this command are cumulative.
::critcl::metakey ?word...?
Provides arbitrary meta data outside of the following reserved keys: as::author, as::build::date,
description, license, name, platform, requiresubject, summary, and version, Its behaviour is like
::critcl::subject in that it treats all keys as list of words, with each call providing 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,
packagerequire, and packageprovide 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
Returns the value in the metadata associated with key.
Used primarily to retrieve the name of the package from within utility packages having to adapt C
code templates to their environment. For example, critcl::class uses does this.
::critcl::buildrequirementscript
Provides control over the capturing of dependencies declared via packagerequire. script is
evaluated and any dependencies declared within are ignored, i.e. not recorded in the meta data.
CONTROL&INTERFACE
These commands control the details of compilation and linking a CriTclscript. The information is used
only to compile/link the object for the CriTclscript. For example, information for "FOO.tcl" is kept
separate from information for "BAR.tcl".
::critcl::cheaders ?arg...?
Provides additional header locations.
Each argument is a glob pattern. If an argument begins with - it is an argument to the compiler.
Otherwise the parent directory of each matching path is a directory to be searched for header
files. Returns an error if a pattern matches no files. A pattern for a relative path is resolved
relative to the directory containing the CriTclscript.
#include lines are not automatically generated for matching header files. Use critcl::include or
critcl::ccode as necessary to add them.
Calls to this command are cumulative.
::critcl::csources ?globpattern...?
Matching paths become inputs to the compilation of the current object along with the sources for
the current CriTclscript. Returns an error if no paths match a pattern. A pattern for a
relative path is resolved relative to the directory containing the CriTclscript.
Calls to this command are cumulative.
::critcl::clibraries ?globpattern...?
provides the link step with additional libraries and library locations. A globpattern that
begins with - is added as an argument to the linker. Otherwise matching files are linked into the
shared library. Returns an error if no paths match a pattern. A pattern for a relative path is
resolved relative to the directory containing the CriTclscript.
Calls to this command are cumulative.
::critcl::sourceglobpattern
Evaluates as scripts the files matching each globpattern. Returns an error if there are no
matching files. A pattern for a relative path is resolved relative to the directory containing
the CriTclscript.
::critcl::tsourcesglobpattern...
Provides the information about additional Tcl script files to source when the shared library is
loaded.
Matching paths are made available to the generated shared library when it is loaded for the
current CriTclscript. Returns an error if a pattern matches no files. A pattern for a relative
path is resolved relative to the directory containing the CriTclscript.
Calls to this command are cumulative.
After the shared library has been loaded, the declared files are sourced in the same order that
they were provided as arguments.
::critcl::ownsglobpattern...
Ignored in "compile and run" and "generate package" modes. In "generate TEA" mode each file
matching a globpattern is a file to be included in the TEA extension but that could not be
ascertained as such from previous commands like critcl::csources and critcl::tsources, either
because of they were specified dynamically or because they were directly sourced.
::critcl::cflags ?arg...?
Each arg is an argument to the compiler.
Calls to this command are cumulative.
::critcl::ldflags ?arg...?
Each arg is an argument to the linker.
Calls to this command are cumulative.
::critcl::framework ?arg...?
Each arg is the name of a framework to link on MacOS X. This command is ignored if OS X is not
the target so that frameworks can be specified unconditionally.
Calls to this command are cumulative.
::critcl::tclversion
Specifies the minimum version of the Tcl runtime to compile and link the package for. The default
is 8.4.
::critcl::tk
Arranges to include the Tk headers and link to the Tk stubs.
::critcl::preloadlib...
Arranges for the external shared library lib to be loaded before the shared library for the CriTclscript is loaded.
Calls to this command are cumulative.
Each library FOO is searched for in the directories listed below, in the order listed. The search
stops at the first existing path. Additional notes:
• platform is the placeholder for the target platform of the package.
• The extension ".so" is the placeholder for whatever actual extension is used by the target
platform for its shared libraries.
• The search is relative to the current working directory.
And now the paths, depending on the exact form of the library name:
FOO
[1] FOO.so
[2] FOO/FOO.so
[3] FOO/platform/FOO.so
PATH/FOO
The exact set searched depends on the existence of directory "PATH/FOO". If it exists,
critcl searches
[1] FOO.so
[2] PATH/FOO/FOO.so
[3] PATH/FOO/platform/FOO.so
Otherwise it searches
[1] FOO.so
[2] PATH/FOO.so
[3] PATH/platform/FOO.so
instead.
/PATH/FOO
Even when specifying FOO with an absolute path the first path searched is relative to the
current working directory.
[1] FOO.so
[2] /PATH/FOO.so
[3] /PATH/platform/FOO.so
For developers who want to understand or modify the internals of the critcl package, Preloadingfunctionality explains how preloading is implemented.
::critcl::debugarea...
Specifies what debugging features to activate. Internally each area is translated into area-
specific flags for the compiler which are then handed over to critcl::cflags.
memory Specifies Tcl memory debugging.
symbols
Specifies compilation and linking with debugging symbols for use by a debugger or other
tool.
all Specifies all available debugging.
INTROSPECTION
The following commands control compilation and linking.
::critcl::check ?label? text
Returns a true if the C code in text compiles sucessfully, and false otherwise. Used to check for
availability of features in the build environment. If provided, label is used to uniquely mark
the results in the generated log.
::critcl::checklink ?label? text
Like critcl::check but also links the compiled objects, returning true if the link is successful
and false otherwise. If specified, label is used to uniquely mark the results in the generated
log.
::critcl::msg ?-nonewline? msg
Scripts using critcl::check and critcl::checklink can use this command to report results. Does
nothing in compile&run mode. Tools like the CriTclAplication may redefine this command to
implement their own message reporting. For example, critcl::app and any packages built on it print
messages to stdout.
::critcl::print ?-nonewline? ?chan? msg
Used by the CriTcl internals to report activity. By default, effectively the same thing as
::puts. Tools directly using either the CriTcl package or the CriTcl application package may
redefine this procedure to implement their own output functionality.
For example, the newest revisions of Kettle
[https://chiselapp.com/user/andreas_kupries/repository/Kettle/index] use this to highlight build
warnings.
::critcl::compiled
Returns true if the current CriTclscript is already compiled and false otherwise.
Enables a CriTclscript used as its own Tcl companion file (see critcl::tsources) to distinguish
between being sourced for compilation in compile&run mode and being sourced from either the
result of generatepackage mode or during the load phase of compile&run mode. The result is
false in the first case and true in the later two cases.
::critcl::compiling
Returns true if a working C compiler is available and false otherwise.
::critcl::done
Returns true when CriTclscript has been built and false otherwise. Only useful from within a
CriTclscript. Enables the Tcl parts of a CriTclscript to distinguish between prebuiltpackage
mode and compile&run mode.
See also ModesOfOperation/Use.
::critcl::failed
Returns true if the CriTclscript could not be built, and false otherwise. Forces the building of
the package if it hasn't already been done, but not its loading. Thus, a CriTclscript can check
itself for availability of the compiled components. Only useful from within a CriTclscript.
::critcl::load
Like critcl::failed except that it also forces the loading of the generated shared library, and
that it returns true on success and false on failure. Thus, a CriTclscript can check itself for
availability of the compiled components. Only useful from within a CriTclscript.
BUILDMANAGEMENT
The following command manages global settings, i.e. configuration options which are independent of any
CriTclscript.
This command should not be needed to write a CriTclscript. It is a management command which is only
useful to the CriTclApplication or similar tools.
::critcl::configoption ?val?
Sets and returns the following global configuration options:
force bool
When false (the default), the C files are not built if there is a cached shared library.
lines bool
When true (the default), #line directives are embedded into the generated C code.
This facility requires the use of a tclsh that provides infoframe. Otherwise, no #line
directives are 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.
Developers of higher-level packages generating their own C code, either directly or
indirectly through critcl, should also read section Advanced:Locationmanagement to see
how critcl helps them in generating their directives. Examples of such packages come with
critcl itself. See critcl::iassoc and critcl::class.
trace bool
When false (the default), no code tracing the entry and exit of CriTcl-backed commands in
the CriTclscript is inserted. Insertion of such code implicitly activates the tracing
facility in general. See critcl::cutil.
I path A single global include path to use for all files. Not set by default.
combine enum
dynamic (the default)
Object files have the suffix _pic.
static Object files have the suffix _stub.
standalone
Object files have no suffix, and the generated C files are compiled without using
Tcl/Tk stubs. The result are object files usable for static linking into a bigshell.
language string
keepsrc bool
When false (the default), the generated ".c" files are deleted after the ".o" files have
been built.
outdir directory
The directory where to place a generated shared library. By default, it is placed into the
ResultCache.
RESULTCACHEMANAGEMENT
The following commands control the ResultCache. These commands are not needed to simply write a CriTclscript.
::critcl::cache ?path?
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...?
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.
BUILDCONFIGURATION
The following commands manage the build configuration, i.e. the per-platform information about compilers,
linkers, and their commandline options. These commands are not needed to simply write a CriTclscript.
::critcl::readconfigpath
Reads the build configuration file at path and configures the package using the information for
the target platform.
::critcl::showconfig ?chan?
Converts the active build configuration into a human-readable string and returns it, or if chan is
provided prints the result to that channel.
::critcl::showallconfig ?chan?
Converts the set of all known build configurations from the currently active build configuration
file last set with critcl::readconfig into a string and returns it, or if chan is provided, prints
it to that channel.
::critcl::chooseconfigtarget ?nomatcherr?
Matches target 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 an error is thrown using critcl::error instead.
::critcl::setconfigtarget
Configures the package to use the settings of target.
TOOLAPI
The following commands provide tools like CriTclApplication or similar with deeper access to the
package's internals. These commands are not needed to simply write a CriTclscript.
::critcl::actualtarget
Returns the platform identifier for the target platform, i.e. the platform to build for. Unlike
::critcl::targetplatform this is the true target, with any cross-compilation information resolved.
::critcl::buildforpackage ?flag?
Signals whether the next file is to be built for inclusion into a package. 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 the loading of that library. It
is expected that the build results are later wrapped into a larger collection.
::critcl::cnothingtodofile
Checks whether there is anything to build for file.
::critcl::cresults ?file?
Returns information about building file, or infoscript If file is not provided. The result in
question is a dictionary containing the following items:
clibraries
A list of external shared libraries and/or directories needed to link file.
ldflags
A list of linker flags needed to link file.
license
The text of the license for the package file is located in.
mintcl The minimum version of Tcl required by the package file is in to run successfully. A proper
Tcl version number.
objects
A list of object files to link into file.
preload
A list of libraries to be preloaded in order to sucessfully load and use file.
tktrue if file requires Tk and false otherwise.
tsources
A list of companion ".tcl" files to source in order to load and use the CriTclscriptfile.
log The full build log generated by the compiler/linker, including command line data from
critcl, and other things.
exl The raw build log generated by the compiler/linker. Contains the output generated by the
invoked applications.
::critcl::crosscheck
Determines whether the package is configured for cross-compilation and prints a message to the
standard error channel if so.
::critcl::errormsg
Used to report internal errors. The default implementation simply returns the error. Tools like
the CriTclApplication 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 notreturn
to the caller.
::critcl::knowntargets
Returns a list of the identifiers of all targets found during the last invocation of
critcl::readconfig.
::critcl::sharedlibext
Returns the file extension for shared libraries on the target platform.
::critcl::targetconfig
Returns the identifier of the target to build for, as specified by either the user or the system.
::critcl::buildplatform
Returns the identifier of the build platform, i.e. where the package is running on.
::critcl::targetplatform
Returns the identifier of the target platform, i.e. the platform to compile for. In contrast to
::critcl::actualtarget this may be the name of a cross-compilation target.
::critcl::cobjects ?globpattern...?
Like ::critcl::clibraries, but instead of matching libraries, each globpattern matches object
files to be linked into the shared object (at compile time, not runtime). If a globpattern
matches nothing an error is returned. Not listed in Control&Interface because it is of no use
to package writers. Only tools like the CriTclApplication need it.
A pattern for a relative path is resolved relative to the directory containing the CriTclscript.
Calls to this command are cumulative.
::critcl::scanpath
The main entry point to CriTcl's static code scanner. Used by tools to implement processing modes
like the assembly of a directory hierarchy containing a TEA-lookalike buildystem, etc.
Scans path and returns a dictionary containing the following items:
version
Package version.
org Author(ing organization).
files List of the companion files, relative to the directory of the input file.
::critcl::name2cname
Given the Tcl-level identifier name, returns a list containing the following details of its
conversion to C:
• Tcl namespace prefix
• C namespace prefix
• Tcl base name
• C base name
For use by utilities that provide Tcl commands without going through standard commands like
critcl::ccommand or critcl::cproc. critcl::class does this.
ADVANCED:EMBEDDEDCCODE
For advanced use, the following commands used by critcl::cproc itself are exposed.
::critcl::argnamesarguments
Given an argument declaration as documented for critcl::cproc, returns a list of the corresponding
user-visible names.
::critcl::argcnamesarguments
Given an argument declaration as documented for critcl::cproc, returns a list of the corresponding
C variable names for the user-visible names. The names returned here match the names used in the
declarations and code returned by ::critcl::argvardecls and ::critcl::argconversion.
::critcl::argcsignaturearguments
Given an argument declaration as documented for critcl::cproc, returns a list of the corresponding
C parameter declarations.
::critcl::argvardeclsarguments
Given an argument declaration as documented for critcl::cproc, returns a list of the corresponding
C variable declarations. The names used in these declarations match the names returned by
::critcl::argcnames.
::critcl::argconversionarguments ?n?
Given an argument declaration as documented for critcl::cproc, 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. The
default is 1.
::critcl::argoptionalarguments
Given an argument declaration as documented for critcl::cproc, returns a list of boolean values
indicating which arguments are optional (true), and which are not (false).
::critcl::argdefaultsarguments
Given an argument declaration as documented for critcl::cproc, returns a list containing the
default values for all optional arguments.
::critcl::argsupportarguments
Given an argument declaration as documented for critcl::cproc, returns a list of C code fragments
needed to define the necessary supporting types.
CUSTOMBUILDCONFIGURATION
This package provides one command for the management of package-specific, i.e. developer-specified custom
build configuration options.
::critcl::userconfigdefinenamedescriptiontype ?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.
[1] For bool the default value, if specified, must be a boolean. If it is not specified it
defaults to true.
[2] For a list of values the default value, if specified, must be a value found in this list.
If it is not specified it defaults to the first value of the list.
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::userconfigqueryname
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::userconfigset.
It is at this point that definitions and set values are brought together, with the latter
validated against the definition.
::critcl::userconfigsetnamevalue
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::userconfigquery.
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:LOCATIONMANAGEMENT
First a small introduction for whose asking themselves ´what is 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.
This facility requires the use of a tclsh that provides infoframe. Otherwise, no #line directives are
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 storedlocation, 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::calleroffset
As above, the stored line number is modified by the specified offset. In essence an implicit call
of critcl::at::incr.
::critcl::at::calleroffsetlevel
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::=fileline
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::incrn...
::critcl::at::incrtstr...
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!offsetlevel::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
Diversions are for higher-level packages generating their own C code, to make their use of critcl's
commands generating EmbeddedCCode easier.
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::collectscript
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:FILEGENERATION
While file generation is related to the diversions explained in the previous section they are not the
same. Even so, like diversions this feature is for higher-level packages generating their own C code.
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::makepathcontents
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.
Install Now
Emojis
PNG Icons
