Provided by: critcl_3.1.18.1+dfsg-3_amd64 
NAME
critcl - Critcl - Package Reference
SYNOPSIS
package require Tcl 8.4
package require critcl ?3.1.18?
package require platform ?1.0.2?
package require md5 ?2?
::critcl::ccode fragment
::critcl::ccommand tclname cname
::critcl::ccommand tclname arguments body ?option value...?
::critcl::cdata tclname data
::critcl::cconst tclname resulttype value
::critcl::cdefines list of glob patterns ?namespace?
::critcl::cproc name arguments resulttype body ?option value...?
::critcl::cproc name arguments resulttype
::critcl::cinit text externals
::critcl::include path
::critcl::api import name version
::critcl::api function resulttype name arguments
::critcl::api header ?glob pattern...?
::critcl::api extheader ?file...?
::critcl::license author ?text...?
::critcl::summary text
::critcl::description text
::critcl::subject ?key...?
::critcl::meta key ?word...?
::critcl::meta? key
::critcl::buildrequirement script
::critcl::cheaders ?arg...?
::critcl::csources ?glob pattern...?
::critcl::clibraries ?glob pattern...?
::critcl::source glob pattern
::critcl::tsources glob pattern...
::critcl::owns glob pattern...
::critcl::cflags ?arg...?
::critcl::ldflags ?arg...?
::critcl::framework ?arg...?
::critcl::tcl version
::critcl::tk
::critcl::preload lib...
::critcl::debug area...
::critcl::check ?label? text
::critcl::checklink ?label? text
::critcl::msg ?-nonewline? msg
::critcl::print ?-nonewline? ?chan? msg
::critcl::compiled
::critcl::compiling
::critcl::done
::critcl::failed
::critcl::load
::critcl::config option ?val?
::critcl::cache ?path?
::critcl::clean_cache ?pattern...?
::critcl::readconfig path
::critcl::showconfig ?chan?
::critcl::showallconfig ?chan?
::critcl::chooseconfig target ?nomatcherr?
::critcl::setconfig target
::critcl::actualtarget
::critcl::buildforpackage ?flag?
::critcl::cnothingtodo file
::critcl::cresults ?file?
::critcl::crosscheck
::critcl::error msg
::critcl::knowntargets
::critcl::sharedlibext
::critcl::targetconfig
::critcl::buildplatform
::critcl::targetplatform
::critcl::cobjects ?glob pattern...?
::critcl::scan path
::critcl::name2c name
::critcl::argnames arguments
::critcl::argcnames arguments
::critcl::argcsignature arguments
::critcl::argvardecls arguments
::critcl::argconversion arguments ?n?
::critcl::argoptional arguments
::critcl::argdefaults arguments
::critcl::argsupport arguments
::critcl::userconfig define name description type ?default?
::critcl::userconfig query name
::critcl::userconfig set name value
::critcl::at::caller
::critcl::at::caller offset
::critcl::at::caller offset level
::critcl::at::here
::critcl::at::get*
::critcl::at::get
::critcl::at::= file line
::critcl::at::incr n...
::critcl::at::incrt str...
::critcl::at::caller!
::critcl::at::caller! offset
::critcl::at::caller! offset level
::critcl::at::here!
::critcl::collect_begin
::critcl::collect_end
::critcl::collect script
::critcl::make path contents
::critcl::has-resulttype name
::critcl::resulttype name body ?ctype?
::critcl::resulttype name = origname
::critcl::has-argtype name
::critcl::argtype name body ?ctype? ?ctypefun?
::critcl::argtype name = origname
::critcl::argtypesupport name code ?guard?
::critcl::argtyperelease name code
::preload library
_________________________________________________________________________________________________
DESCRIPTION
C Runtime In Tcl, or CriTcl , is a system for compiling C code embedded in Tcl on the fly
and either loading the resulting objects into Tcl for immediate use or packaging them for
distribution. Use CriTcl to improve performance by rewriting in C those routines that are
performance bottlenecks.
The critcl package is the core of the system. For an overview of the complete system, see
Introduction To CriTcl. For the usage of the standalone critcl program, see CriTcl
Application. This core package maybe be used to embed C code into Tcl scripts. It also
provides access to the internals that other parts of the core use and which are of
interest to those wishing to understand the internal workings of the core and of the API
it provides to the CriTcl Application. These advanced sections are marked as such so that
those simply wishing to use the package can skip them.
This package resides in the Core Package Layer of CriTcl.
+----------------+
|Applications |
| critcl |
| critcl::app |
+----------------+
*================*
|Core Packages |
| critcl |
| critcl::util |
*================*
+----------------+
|Support Packages|
| stubs::* |
| md5, platform |
| ... |
+----------------+
API
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 Critcl script. A file containing a Critcl script usually has the extension .tcl
or .critcl.
EMBEDDED C CODE
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::ccode fragment
Appends the C code in fragment to the current module and returns the empty string.
See Runtime Behaviour.
::critcl::ccommand tclname cname
As documented below, except that cname is the name of a C function that already
exists.
::critcl::ccommand tclname arguments body ?option value...?
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
Runtime Behaviour.
Returns the empty string.
Each option may be one of:
-clientdata c-expression
Provides the client data for the new command. NULL by default.
-delproc c-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.
-cname boolean
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::cdata tclname data
Appends the code to create a new Tcl command named tclname which returns data as a
ByteArray result.
Returns the empty string.
::critcl::cconst tclname resulttype value
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::cdefines list of glob patterns ?namespace?
Arranges for C enum and #define values that match one of the patterns in glob
patterns 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::cproc name arguments resulttype body ?option value...?
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
Runtime Behaviour.
Returns the empty string.
string option
Each may be one of:
-cname boolean
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-cdata boolean
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-offset int
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 one of the following predefined types or a custom type. For the
latter see section Advanced: Extending cproc. Unless otherwise noted, the
Tcl return code is always TCL_OK. Before going into the details first a
quick overview:
Critcl type | C type | Tcl type | Notes
------------- | -------------- | --------- | ------------------------------
void | n/a | n/a | Always OK. Body sets result
ok | int | n/a | Result code. Body sets result
------------- | -------------- | --------- | ------------------------------
int | int | Int |
boolean | | | Alias of int above
bool | | | Alias of int above
long | long | Long |
wideint | Tcl_WideInt | WideInt |
double | double | Double |
float | float | Double |
------------- | -------------- | --------- | ------------------------------
char* | char* | String | Makes a copy
vstring | | | Alias of char* above
const char* | const char* | | Behavior of char* above
------------- | -------------- | --------- | ------------------------------
string | | String | Freeable string set directly
| | | No copy is made
dstring | | | Alias of string above
------------- | -------------- | --------- | ------------------------------
| | | For all below: Null is ERROR
| | | Body has to set any message
Tcl_Obj* | Tcl_Obj* | Any | refcount --
object | | | Alias of Tcl_Obj* above
Tcl_Obj*0 | | Any | refcount unchanged
object0 | | | Alias of Tcl_Obj*0 above
------------- | -------------- | --------- | ------------------------------
known-channel | Tcl_Channel | String | Assumes to already be registered
new-channel | Tcl_Channel | String | New channel, will be registered
And now the details:
Tcl_Obj*
object If the returned Tcl_Obj* is NULL, the Tcl return code is TCL_ERROR
and the function should set an error mesage [https://www.tcl-
lang.org/man/tcl/TclLib/SetResult.htm] as the interpreter result.
Otherwise, the returned Tcl_Obj* is set as the interpreter result.
Note that setting an error message requires the function body to have
access to the interpreter the function is running in. See the
argument type Tcl_Interp* for the details on how to make that happen.
Note further that the returned Tcl_Obj* should have a reference count
greater than 0. This is because the converter decrements the
reference count to release possession after setting the interpreter
result. It assumes that the function incremented the reference count
of the returned Tcl_Obj*. If a Tcl_Obj* with a reference count of 0
were returned, the reference count would become 1 when set as the
interpreter result, and immediately thereafter be decremented to 0
again, causing the memory to be freed. The system is then likely to
crash at some point after the return due to reuse of the freed
memory.
Tcl_Obj*0
object0
Like Tcl_Obj* except that this conversion assumes that the returned
value has a reference count of 0 and does not decrement it. Returning
a value whose reference count is greater than 0 is therefore likely
to cause a memory leak.
Note that setting an error message requires the function body to have
access to the interpreter the function is running in. See the
argument type Tcl_Interp* for the details on how to make that happen.
new-channel
A String Tcl_Obj holding the name of the returned Tcl_Channel is set
as the interpreter result. The channel is further assumed to be new,
and therefore registered with the interpreter to make it known.
known-channel
A String Tcl_Obj holding the name of the returned Tcl_Channel is set
as the interpreter result. The channel is further assumed to be
already registered with the interpreter.
return-channel
This type is a variant of new-channel above. It varies slightly from
it in the registration sequence to be properly complementary to the
argument type take-channel. A String Tcl_Obj holding the name of the
returned Tcl_Channel is set as the interpreter result. The channel
is further assumed to be new, and therefore registered with the
interpreter to make it known.
char*
vstring
A String Tcl_Obj holding a copy of the returned char* is set as the
interpreter result. If the value is allocated then the function
itself and the extension it is a part of are responsible for
releasing the memory when the data is not in use any longer.
const char*
Like char* above, except that the returned string is const-qualified.
string
dstring
The returned char* is directly set as the interpreter result without
making a copy. Therefore it must be dynamically allocated via
Tcl_Alloc. Release happens automatically when the Interpreter finds
that the value is not required any longer.
double
float The returned double or float is converted to a Double Tcl_Obj and set
as the interpreter result.
boolean
bool The returned int value is converted to an Int Tcl_Obj and set as the
interpreter result.
int The returned int value is converted to an Int Tcl_Obj and set as the
interpreter result.
long The returned long int value is converted to a Long Tcl_Obj and set as
the interpreter result.
wideint
The returned Tcl_WideInt value is converted to a WideInt Tcl_Obj and
set as the interpreter result.
ok The returned int value becomes the Tcl return code. The interpreter
result is left untouched and can be set by the function if desired.
Note that doing this requires the function body to have access to the
interpreter the function is running in. See the argument type
Tcl_Interp* for the details on how to make that happen.
void The function does not return a value. The interpreter result is left
untouched and can be set by the function if desired.
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 one of the following predefined types or a custom
type. For the latter see Advanced: Extending cproc. Before going into the
details first a quick overview:
Critcl type | C type | Tcl type | Notes
----------- | -------------- | --------- | ------------------------------
Tcl_Interp* | Tcl_Interp* | n/a | Special, only first
----------- | -------------- | --------- | ------------------------------
Tcl_Obj* | Tcl_Obj* | Any | Read-only
object | | | Alias of Tcl_Obj* above
list | critcl_list | List | Read-only
----------- | -------------- | --------- | ------------------------------
char* | const char* | Any | Read-only, string rep
pstring | critcl_pstring | Any | Read-only
bytes | critcl_bytes | ByteArray | Read-only
----------- | -------------- | --------- | ------------------------------
int | int | Int |
long | long | Long |
wideint | Tcl_WideInt | WideInt |
double | double | Double |
float | float | Double |
----------- | -------------- | --------- | ------------------------------
X > 0 | | | For X in int ... float above.
X >= 0 | | | C types as per the base type X.
X < 0 | | | Allowed argument values are
X <= 0 | | | restricted as per the shown
X > 1 | | | relation
X >= 1 | | |
X < 1 | | | This is not a general mechanism
X <= 1 | | | open to other values. Only 0/1.
----------- | -------------- | --------- | ------------------------------
boolean | int | Boolean |
bool | | | Alias of boolean above
----------- | -------------- | --------- | ------------------------------
bytearray | | | DEPRECATED
rawchar | | | DEPRECATED
rawchar* | | | DEPRECATED
double* | | | DEPRECATED
float* | | | DEPRECATED
int* | | | DEPRECATED
void* | | | DEPRECATED
And now the details:
Tcl_Interp*
Attention: This is a special argument type. It can only be used by
the first argument of a function. Any other argument using it will
cause critcl to throw an error.
When used, the argument will contain a reference to the current
interpreter that the function body may use. Furthermore the argument
will not be an argument of the Tcl command for the function.
This is useful when the function has to do more than simply returning
a value. Examples would be setting up error messages on failure, or
querying the interpreter for variables and other data.
Tcl_Obj*
object The function takes an argument of type Tcl_Obj*. No argument
checking is done. The Tcl level word is passed to the argument as-
is. Note that this value must be treated as read-only (except for
hidden changes to its intrep, i.e. shimmering).
pstring
The function takes an argument of type critcl_pstring containing the
original Tcl_Obj* reference of the Tcl argument, plus the length of
the string and a pointer to the character array.
typedef struct critcl_pstring {
Tcl_Obj* o;
const char* s;
int len;
} critcl_pstring;
Note the const. The string is read-only. Any modification can have
arbitrary effects, from pulling out the rug under the script because
of string value and internal representation not matching anymore, up
to crashes anytime later.
list The function takes an argument of type critcl_list containing the
original Tcl_Obj* reference of the Tcl argument, plus the length of
the Tcl list and a pointer to the array of the list elements.
typedef struct critcl_list {
Tcl_Obj* o;
Tcl_Obj* const* v;
int c;
} critcl_list;
The Tcl argument must be convertible to List, an error is thrown
otherwise.
Note the const. The list is read-only. Any modification can have
arbitrary effects, from pulling out the rug under the script because
of string value and internal representation not matching anymore, up
to crashes anytime later.
bytearray
rawchar*
rawchar
The function takes an argument of type char*. The Tcl argument must
be convertible to ByteArray, an error is thrown otherwise. Note that
the length of the ByteArray is not passed to the function, making
this type not very usable.
Attention: These types are considered DEPRECATED. It is planned to
remove their documentation in release 3.2, and their implementation
in release 3.3. Their deprecation can be undone if good use cases
are shown.
bytes This is the new and usable ByteArray type.
The function takes an argument of type critcl_bytes containing the
original Tcl_Obj* reference of the Tcl argument, plus the length of
the byte array and a pointer to the byte data.
typedef struct critcl_bytes {
Tcl_Obj* o;
const unsigned char* s;
int len;
} critcl_list;
The Tcl argument must be convertible to ByteArray, an error is thrown
otherwise.
Note the const. The bytes are read-only. Any modification can have
arbitrary effects, from pulling out the rug under the script because
of string value and internal representation not matching anymore, up
to crashes anytime later.
char* The function takes an argument of type const char*. The string
representation of the Tcl argument is passed in.
Note the const. The string is read-only. Any modification can have
arbitrary effects, from pulling out the rug under the script because
of string value and internal representation not matching anymore, up
to crashes anytime later.
double The function takes an argument of type double. The Tcl argument must
be convertible to Double, an error is thrown otherwise.
double > 0
double >= 0
double < 0
double <= 0
double > 1
double >= 1
double < 1
double <= 1
These are variants of double above, restricting the argument value to
the shown relation. An error is thrown for Tcl arguments outside of
the specified range. Note: This is not a general range specification
syntax. Only the listed types exist.
float The function takes an argument of type float. The Tcl argument must
be convertible to Double, an error is thrown otherwise.
float > 0
float >= 0
float < 0
float <= 0
float > 1
float >= 1
float < 1
float <= 1
These are variants of float above, restricting the argument value to
the shown relation. An error is thrown for Tcl arguments outside of
the specified range. Note: This is not a general range specification
syntax. Only the listed types exist.
boolean
bool The function takes an argument of type int. The Tcl argument must be
convertible to Boolean, an error is thrown otherwise.
channel
The function takes an argument of type Tcl_Channel. The Tcl argument
must be convertible to type Channel, an error is thrown otherwise.
The channel is further assumed to be already registered with the
interpreter.
unshared-channel
This type is an extension of channel above. All of the information
above applies.
Beyond that the channel must not be shared by multiple interpreters,
an error is thrown otherwise.
take-channel
This type is an extension of unshared-channel above. All of the
information above applies.
Beyond that the code removes the channel from the current interpreter
without closing it, and disables all pre-existing event handling for
it.
With this the function takes full ownership of the channel in
question, taking it away from the interpreter invoking it. It is then
responsible for the lifecycle of the channel, up to and including
closing it.
Should the system the function is a part of wish to return control of
the channel back to the interpeter it then has to use the result type
return-channel. This will undo the registration changes made by this
argument type. Note however that the removal of pre-existing event
handling done here cannot be undone.
Attention Removal from the interpreter without closing the channel is
effected by incrementing the channel's reference count without
providing an interpreter, before decrementing the same for the
current interpreter. This leaves the overall reference count intact
without causing Tcl to close it when it is removed from the
interpreter structures. At this point the channel is effectively a
globally-owned part of the system not associated with any
interpreter.
The complementary result type then runs this sequence in reverse. And
if the channel is never returned to Tcl either the function or the
system it is a part of have to unregister the global reference when
they are done with it.
int The function takes an argument of type int. The Tcl argument must be
convertible to Int, an error is thrown otherwise.
int > 0
int >= 0
int < 0
int <= 0
int > 1
int >= 1
int < 1
int <= 1
These are variants of int above, restricting the argument value to
the shown relation. An error is thrown for Tcl arguments outside of
the specified range. Note: This is not a general range specification
syntax. Only the listed types exist.
long The function takes an argument of type long int. The Tcl argument
must be convertible to Long, an error is thrown otherwise.
long > 0
long >= 0
long < 0
long <= 0
long > 1
long >= 1
long < 1
long <= 1
These are variants of long above, restricting the argument value to
the shown relation. An error is thrown for Tcl arguments outside of
the specified range. Note: This is not a general range specification
syntax. Only the listed types exist.
wideint
The function takes an argument of type Tcl_WideInt. The Tcl argument
must be convertible to WideInt, an error is thrown otherwise.
wideint > 0
wideint >= 0
wideint < 0
wideint <= 0
wideint > 1
wideint >= 1
wideint < 1
wideint <= 1
These are variants of wideint above, restricting the argument value
to the shown relation. An error is thrown for Tcl arguments outside
of the specified range. Note: This is not a general range
specification syntax. Only the listed types exist.
void*
double*
float*
int* The function takes an argument of the same-named C type. The Tcl
argument must be convertible to ByteArray, an error is thrown
otherwise. The bytes in the ByteArray are then re-interpreted as the
raw representation of a single C pointer of the given type which is
then passed as argument to the function. In other words, this is for
Tcl values somehow holding raw C pointers, i.e. memory addresses.
Attention: These types are considered DEPRECATED. It is planned to
remove their documentation in release 3.2, and their implementation
in release 3.3. Their deprecation can be undone if good use cases
are shown.
::critcl::cproc name arguments resulttype
As documented below, but used when the C function named name already exists.
::critcl::cinit text externals
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
Critcl script relative to this command. Thus, all their content is visible. See
also Runtime Behaviour.
The C code in text is placed into the body of the initialization function of the
shared library backing the Critcl script, 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::include path
This command is a convenient shorthand for
critcl::code {
#include <${path}>
}
STUBS TABLE MANAGEMENT
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 Stubs Tables for the
details of Critcl's particular variant.
Importing stubs tables, i.e. APIs, from another extension:
::critcl::api import name version
Adds the following include directives into the Critcl script and 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::api header, below. An
#include directive is added at the beginning of the generated code for Critcl
script 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 Critcl script , 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 Critcl script:
::critcl::api function resulttype name arguments
Adds to the public API of the Critcl script 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::api import.
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::api header ?glob pattern...?
Each file matching a glob pattern is copied into the directory containing the
generated headers, and an #include directive for it is added to "Decls.h" for the
Critcl script. Returns an error if a glob pattern matches nothing.
A pattern for a relative path is resolved relative to the directory containing the
Critcl script.
::critcl::api extheader ?file...?
Like ::critcl::api header, 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 Critcl script and to each companion ".c" file.
In "compile & run" mode the generated header files and any companion headers are placed in
the Result Cache subdirectory for the Critcl script. 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::api header as a source of
companion files. It also uses data from calls to critcl::api import 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.
PACKAGE META DATA
Critcl versions 3 and later can create TEApot meta-data to be placed into "teapot.txt" in
a format suitable for use by the TEApot tools
[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::license author ?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 Critcl
script.
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::summary text
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::description text
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::meta key ?word...?
Provides arbitrary meta data outside of the following 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 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, 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
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::buildrequirement script
Provides control over the capturing of dependencies declared via package require.
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 Critcl script. The
information is used only to compile/link the object for the Critcl script. 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
Critcl script.
#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 ?glob pattern...?
Matching paths become inputs to the compilation of the current object along with
the sources for the current Critcl script. Returns an error if no paths match a
pattern. A pattern for a relative path is resolved relative to the directory
containing the Critcl script.
Calls to this command are cumulative.
::critcl::clibraries ?glob pattern...?
provides the link step with additional libraries and library locations. A glob
pattern 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 Critcl script.
Calls to this command are cumulative.
::critcl::source glob pattern
Evaluates as scripts the files matching each glob pattern. Returns an error if
there are no matching files. A pattern for a relative path is resolved relative to
the directory containing the Critcl script.
::critcl::tsources glob pattern...
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 Critcl script. Returns an error if a pattern matches no files. A
pattern for a relative path is resolved relative to the directory containing the
Critcl script.
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::owns glob pattern...
Ignored in "compile and run" and "generate package" modes. In "generate TEA" mode
each file matching a glob pattern 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::tcl version
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::preload lib...
Arranges for the external shared library lib to be loaded before the shared library
for the Critcl script 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, Preloading functionality explains how preloading is implemented.
::critcl::debug area...
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 CriTcl Aplication 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 Critcl script is already compiled and false otherwise.
Enables a Critcl script 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 generate package 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 Critcl script has been built and false otherwise. Only useful
from within a Critcl script. Enables the Tcl parts of a Critcl script to
distinguish between prebuilt package mode and compile & run mode.
See also Modes Of Operation/Use.
::critcl::failed
Returns true if the Critcl script 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 Critcl script can check itself for availability of the compiled components.
Only useful from within a Critcl script.
::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 Critcl
script can check itself for availability of the compiled components. Only useful
from within a Critcl script.
BUILD MANAGEMENT
The following command manages global settings, i.e. configuration options which are
independent of any Critcl script.
This command should not be needed to write a Critcl script. It is a management command
which is only useful to the CriTcl Application or similar tools.
::critcl::config option ?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 info frame.
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:
Location management 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 Critcl script 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 big shell.
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 Result Cache.
RESULT CACHE MANAGEMENT
The following commands control the Result Cache. These commands are not needed to simply
write a Critcl script.
::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.
BUILD CONFIGURATION
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 Critcl script.
::critcl::readconfig path
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::chooseconfig target ?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::setconfig target
Configures the package to use the settings of target.
TOOL API
The following commands provide tools like CriTcl Application or similar with deeper access
to the package's internals. These commands are not needed to simply write a Critcl
script.
::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::cnothingtodo file
Checks whether there is anything to build for file.
::critcl::cresults ?file?
Returns information about building file, or info script 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.
tk true if file requires Tk and false otherwise.
tsources
A list of companion ".tcl" files to source in order to load and use the
Critcl script file.
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::error msg
Used to report internal errors. The default implementation simply returns 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
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 ?glob pattern...?
Like ::critcl::clibraries, but instead of matching libraries, each glob pattern
matches object files to be linked into the shared object (at compile time, not
runtime). If a glob pattern matches nothing an error is returned. Not listed in
Control & Interface because it is of no use to package writers. Only tools like the
CriTcl Application need it.
A pattern for a relative path is resolved relative to the directory containing the
Critcl script.
Calls to this command are cumulative.
::critcl::scan path
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::name2c name
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: EMBEDDED C CODE
For advanced use, the following commands used by critcl::cproc itself are exposed.
::critcl::argnames arguments
Given an argument declaration as documented for critcl::cproc, returns a list of
the corresponding user-visible names.
::critcl::argcnames arguments
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::argcsignature arguments
Given an argument declaration as documented for critcl::cproc, returns a list of
the corresponding C parameter declarations.
::critcl::argvardecls arguments
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::argconversion arguments ?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::argoptional arguments
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::argdefaults arguments
Given an argument declaration as documented for critcl::cproc, returns a list
containing the default values for all optional arguments.
::critcl::argsupport arguments
Given an argument declaration as documented for critcl::cproc, returns a list of C
code fragments needed to define the necessary supporting types.
CUSTOM BUILD CONFIGURATION
This package provides one command for the management of package-specific, i.e. developer-
specified custom build configuration options.
::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.
[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::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
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 info frame. 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 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
Diversions are for higher-level packages generating their own C code, to make their use of
critcl's commands generating Embedded C Code 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::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
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::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
While the critcl::cproc command understands the most common C types (see section Embedded
C Code), sometimes this is not enough.
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 already declared an error is 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:
interp A Tcl_Interp* typed C variable referencing the interpreter the result has to
be stored into.
rv The C variable holding the result to convert, of type ctype.
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. ctype is the C type of the variable to
hold the conversion result and ctypefun is the type of the function argument
itself. Both types default to name if they are the empty string or are not
provided.
If name is already declared an error is thrown.
body is a C code fragment that converts a Tcl_Obj* into a C value which is stored
in a helper variable in the underlying function.
body is called inside its own code block to isolate local variables, and the
following items are in scope:
interp A variable of type Tcl_Interp* which is the interpreter the code is running
in.
@@ A placeholder for an expression that evaluates to the Tcl_Obj* to convert.
@A A placeholder for the name of the variable to store the converted argument
into.
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 is 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 is 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.
CONCEPTS
MODES OF OPERATION/USE
CriTcl can be used in three different modes of operation, called
[1] Compile & Run, and
[2] Generate Package
[3] Generate TEA Package
Compile & Run was the original mode and is the default for critcl_pkg. Collects the C
fragments from the Critcl script, builds them as needed, and caches the results to improve
load times later.
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
The default behaviour of critcl, the package is to defer the compilation, linking, and
loading of any C code as much as possible, given that this is an expensive operation,
mainly in the time required. In other words, the C code embedded into a ".critcl" file is
built only when the first C command or procedure it provides is invoked. This part of the
system uses standard functionality built into the Tcl core, i.e. the auto_index variable
to map from commands to scripts providing them and the unknown command using this
information when the command is needed.
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
Each ".critcl" file is backed by a single private ".c" file containing that code, plus the
boilerplate necessary for its compilation and linking as a single shared library.
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
The compilation of C code is time-consuming critcl not only defers it as much as possible,
as described in section Runtime Behaviour, but also caches the results.
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
The audience of this section are developers wishing to understand and possibly modify the
internals of critcl package and application. Package writers can skip this section.
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
The audience of this section are developers wishing to understand and possibly modify the
internals of critcl package and application. Package writers can skip this section.
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. Only the last definition of a variable is 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
also wishing to interface with stubs as they are understood and used by critcl, either by
exporting their own stubs table to a critcl-based extension, or importing a stubs table of
a critcl-based extension into their own.
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):
[1] the declarations of the exported, i.e. public, functions of foo,
[2] the declaration of structure "FooStubs" for the stub table,
[3] the C preprocessor macros which route the invocations of the public
functions through the stubs table.
These macros must be defined if, and only if, the C preprocessor macro
USE_FOO_STUBS is defined. Package foo does not define this macro, as it is
allowed to use the exported functions directly. All importing packages
however must define this macro, to ensure that they do not use any of the
exported functions directly, but only through the stubs table.
[4] If the exported functions need additional types for their proper declaration
then these types should be put into a separate header file (of arbitrary
name) and "fooDecls.h" should contain an #include directive to this header
at the top.
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):
[1] An #include directive for "tcl.h", with USE_TCL_STUBS surely defined.
[2] An #include directive for "fooDecls.h", with USE_FOO_STUBS surely defined.
[3] A definition of the stubs table variable, i.e.
const FooStubs* fooStubsPtr;
[4] A definition of the stubs initializer function, like
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;
}
EXAMPLES
See section "Embedding C" in Using CriTcl.
The latest changes are found at the top.
CHANGES FOR VERSION 3.1.18.1
[1] Attention: While the overall version (of the bundle) moves to 3.1.18.1 the versions
of packages critcl and critcl::app are unchanged.
[2] Bugfix Generally removed a number of 8.5-isms which slipped into 3.1.18, breaking
ability to use it with Tcl 8.4.
[3] Bugfix Corrected broken build.tcl uninstall.
[4] Bugfix Package critcl::class bumped to version 1.1.1. Fixed partial template
substitution breaking compilation of the generated code.
CHANGES FOR VERSION 3.1.18
[1] Feature (Developer support). Merged pull request #96 from sebres/main-direct-
invoke. Enables direct invokation of the "main.tcl" file for starkits from within a
dev checkout, i.e. outside of a starkit, or starpack.
[2] Feature. Added channel types to the set of builtin argument and result types. The
argument types are for simple channel access, access requiring unshared channels,
and taking the channel fully into the C level, away from Tcl. The result type comes
in variants for newly created channels, known channels, and to return taken
channels back to Tcl. The first will register the returned value in the
interpreter, the second assumes that it already is.
[3] Bugfix. Issue #96. Reworked the documentation around the argument type Tcl_Interp*
to make its special status more visible, explain uses, and call it out from result
types where its use will be necessary or at least useful.
[4] Feature. Package critcl::class bumped to version 1.1. Extended with the ability to
create a C API for classes, and the ability to disable the generation of the Tcl
API.
[5] Bugfix. Merged pull request #99 from pooryorick/master. Fixes to the target
directory calculations done by the install code.
[6] Merged pull request #94 from andreas-kupries/documentation. A larger documentation
cleanup. The main work was done by pooryorick, followed by tweaks done by myself.
[7] Extended the test suite with lots of cases based on the examples for the various
generator packages. IOW the new test cases replicate/encapsulate the examples and
demonstrate that the packages used by the examples generate working code.
[8] Bugfix. Issue #95. Changed the field critcl_bytes.s to unsigned char* to match
Tcl's type. Further constified the field to make clear that read-only usage is the
common case for it.
[9] Bugfix/Feature. Package critcl::cutil bumped to version 0.2. Fixed missing
inclusion of header "string.h" in "critcl_alloc.h", needed for memcpy in macro
STREP. Added macros ALLOC_PLUS and STRDUP. Moved documentation of STREP... macros
into proper place (alloc section, not assert).
[10] Merged pull request #83 from apnadkarni/vc-fixes. Removed deprecated -Gs for MSVC
builds, and other Windows fixups.
[11] Feature. Package critcl::iassoc bumped to version 1.1. Refactored internals to
generate an include header for use by .c files. This now matches what other
generator packages do. The template file is inlined and removed.
[12] Merged pull request #82 from gahr/home-symlink Modified tests to handle possibility
of $HOME a symlink.
[13] Merged pull request #81 from gahr/test-not-installed Modified test support to find
uninstalled critcl packages when running tests. Handles all but critcl::md5.
[14] Merged pull request #85 from snoe925/issue-84 to fix Issue #84 breaking
installation on OSX.
[15] Merged pull request #87 from apnadkarni/tea-fixes to fix Issue #86, broken -tea
option, generating an incomplete package.
[16] Feature. New package critcl::callback providing C-level functions and data
structures to manage callbacks from C to Tcl.
[17] Feature. Package critcl::literals bumped to version 1.3. Added mode +list enabling
the conversion of multiple literals into a list of their strings.
[18] Feature. Package critcl::enum bumped to version 1.1. Added basic mode handling,
supporting tcl (default) and +list (extension enabling the conversion of multiple
enum values into a list of their strings).
[19] Feature. Package critcl::emap bumped to version 1.2. Extended existing mode
handling with +list extension enabling the conversion of multiple emap values into
a list of their strings.
[20] Feature. Extended the set of available types by applying a few range restrictions
to the scalar types (int, long, wideint, double, float).
Example: int > 0 is now a viable type name.
This is actually more limited than the description might let you believe.
See the package reference for the details.
CHANGES FOR VERSION 3.1.17
[1] Extension: Allow duplicate arg- and result-type definitions if they are fully
identical.
[2] Bugfix. The application mishandled the possibility of identical-named
critcl::tsources. Possible because critcl::tsources can be in subdirectories, a
structure which is not retained in the assembled package, causing such files to
overwrite each other and at least one lost. Fixed by adding a serial number to the
file names in the assembled package.
[3] Bugfix in the static scanner which made it loose requirement information. Further
added code to generally cleanup results at the end (removal of duplicates, mainly).
[4] Bugfix: Fixed issue #76. Support installation directories which are not in the
auto_path. Without the patch the installed critcl will not find its own packages
and fail. Thank you to Simon Bachmann [https://github.com/lupylucke] for the report
and patch, and then his patience with me to getting to actually apply it.
[5] Bugfix: Fixed issue #75. Extended critcl::include to now take multiple paths.
[6] Added new compatibility package lmap84.
[7] Fixed typos in various documentation files.
[8] Fixed bug introduced by commit 86f415dd30 (3.1.16 release). The separation of
critcl::ccode into user and work layers means that location retrieval has to go one
more level up to find the user location.
[9] New supporting package critcl::cutil. Provides common C level facilities useful to
packages (assertions, tracing, memory allocation shorthands).
[10] Modified package critcl to make use of the new tracing facilities to provide
tracing of arguments and results for critcl::ccommand and critcl::cproc
invokations.
[11] Modified packages critcl and critcl::class to provide better function names for
(class) method tracing. Bumped package critcl::class to version 1.0.7.
[12] Extended the support package critcl::literals with limited configurability. It is
now able to generate code for C-level access to the pool without Tcl types (Mode
c). The previously existing functionality is accesssible under mode tcl, which
also is the default. Both modes can be used together.
[13] Extended the support package critcl::emap with limited configurability. It is now
able to generate code for C-level access to the mapping without Tcl types (Mode c).
The previously existing functionality is accessible under mode tcl, which also is
the default. Both modes can be used together.
CHANGES FOR VERSION 3.1.16
[1] New feature. Extended critcl::cproc's argument handling to allow arbitrary mixing
of required and optional arguments.
[2] New feature. Potential Incompatibility.
Extended critcl::cproc's argument handling to treat an argument args as variadic if
it is the last argument of the procedure.
[3] New feature. Added two introspection commands, critcl::has-argtype and critcl::has-
resulttype. These enable a user to test if a specific (named) type conversion is
implemented or not.
[4] Added new result type Tcl_Obj*0, with alias object0. The difference to Tcl_Obj* is
in the reference counting.
[5] Extended the command critcl::argtypesupport with new optional argument through
which to explicitly specify the identifier for guarding against multiple
definitions.
[6] Bugfix: Fixed problem with the implementation of issue #54 (See 3.1.14). Always
create the secondary log file. Otherwise end-of-log handling may break,
unconditionally assuming its existence.
[7] Bugfix: Fixed problem with the internal change to the hook HandleDeclAfterBuild.
Corrected the forgotten critcl::cconst.
[8] Debugging aid: Added comment holding the name of the result type when emitting
result conversions.
[9] Bugfix: Fixed issue #60. Unbundled the package directories containing multiple
packages. All directories under "lib/" now contain exactly one package.
[10] Bugfix: Fixed issue #62, a few dict exists commands operating on a fixed string
instead of a variable.
[11] Bugfix: Fixed issue #56. Release builders are reminded to run the tests.
[12] Bugfix: Fixed issue #55. For FreeBSD critcl's platform package now identifies the
Kernel ABI version. Initialization of the cache directory now also uses
platform::identify for the default path, instead of platform::generic.
[13] Bugfix: Fixed issue #58. Simplified the setup and use of md5. Critcl now makes use
of its own package for md5, using itself to built it. There is no chicken/egg
problem with this as the -pkg mode used for this does not use md5. That is limited
to mode compile & run.
CHANGES FOR VERSION 3.1.15
[1] Fixed version number bogosity with 3.1.14.
CHANGES FOR VERSION 3.1.14
[1] Fixed issue #36. Added message to target all of the Makefile generated for TEA
mode. Additionally tweaked other parts of the output to be less noisy.
[2] Accepted request implied in issue #54. Unconditionally save the compiler/linker
build log into key log of the dictionary returned by cresults, and save a copy of
only the execution output in the new key exl ("execution log").
[3] Fixed issue #53. Clarified the documentation of commands critcl::load and
critcl::failed with regard to their results and the throwing of errors (does not
happen).
[4] Fixed issue #48. Modified mode "compile & run" to allow new declarations in a file,
after it was build, instead of erroring out. The new decls are build when needed.
Mode "precompile" is unchanged and will continue to trap the situation.
[5] Fixed issue #52. Updated the local Tcl/Tk headers to 8.4.20, 8.5.13, and 8.6.4.
[6] Fixed issue #45. New feature command critcl::cconst.
[7] critcl::util: New command locate to find a file across a set of paths, and report
an error when not found. This is for use in autoconf-like header-searches and
similar configuration tests.
[8] Modified 'AbortWhenCalledAfterBuild' to dump the entire stack (info frame!). This
should make it easier to determine the location of the troubling declaration.
CHANGES FOR VERSION 3.1.13
[1] Merged PR #43. Fixed bug loading adjunct Tcl sources.
[2] Fixes in documentation and generated code of package "critcl::enum". Bumped to
version 1.0.1.
[3] Fixes in documentation of package "critcl::bitmap".
[4] New package "critcl::emap". In essence a variant or cross of "critcl::bitmap" with
behaviour like "critcl::enum".
[5] Merged PR #49. Fixed documentation typo.
[6] Merged PR #46. Fixed documentation typo.
[7] Merged PR #47. Fixes to test results to match the accumulated code changes. Also
made portable across Tcl versions (varying error syntax).
[8] New predefined argument- and result-type "wideint" mapping to Tcl_WideInt.
[9] New predefined argument-type "bytes" mapping to tuple of byte-array data and
length. Note: The existing "bytearray" type (and its aliases) was left untouched,
to keep backward compatibility.
[10] Modified the internal interface between the Tcl shim and C function underneath
"critcl::cproc" with respect to the handling of optional arguments. An optional
argument "X" now induces the use of two C arguments, "X" and "has_X". The new
argument "has_X" is of boolean (int) type. It is set to true when X is set, and set
to false when X has the default value. C code which cares about knowing if the
argument is default or not is now able to check that quickly, without having to
code the default value inside. NOTE: This change is visible in the output of the
advanced commands "argcnames", "argcsignature", "argvardecls", and "argconversion".
[11] Fixed issue #50 and documented the availability of variable "interp" (type
Tcl_Interp*) within "critcl::cinit" C code fragments. Note that while the old,
undocumented name of the variable, "ip", is still usable, it is deprecated. It will
be fully removed in two releases, i.e. for release 3.1.15. The variable name was
changed to be consistent with other code environments.
[12] Fixed issue #51. Disabled the generation of #line directives for "critcl::config
lines 0" coming from template files, or code generated with them before the final
value of this setting was known.
[13] Fixed issue with handling of namespaced package names in "critcl::iassoc".
Equivalent to a bug in "critcl::class" fixed for critcl 3.1.1, critcl::class 1.0.1.
Note: "literals", "enum", "emap", and "bitmap" do not require a fix as they are all
built on top of "iassoc".
CHANGES FOR VERSION 3.1.12
[1] Fixed issue 42. Clear ::errorInfo immediately after startup to prevent leakage of
irrelevant (caught) errors into our script and confusing the usage code.
[2] Fixed issue 40. Keep the order of libraries, and allow duplicates. Both are things
which are occasionally required for proper linking.
[3] Extended the utility package critcl::literals to declare a cproc result-type for a
pool.
Further fixed the generated header to handle multiple inclusion.
Bumped version to 1.1.
[4] Fixed issue with utility package critcl::bitmap.
Fixed the generated header to handle multiple inclusion.
Bumped version to 1.0.1.
[5] Created new utility package critcl::enum for the quick and easy setup and use of
mappings between C values and Tcl strings. Built on top of critcl::literals.
[6] Added examples demonstrating the use of the utility packages critcl::literals,
critcl::bitmap, and critcl::enum
CHANGES FOR VERSION 3.1.11
[1] Fixed issue #37, via pull request #38, with thanks to Jos DeCoster. Information was
stored into the v::delproc and v::clientdata arrays using a different key than when
retrieving the same information, thus failing the latter.
[2] New convenience command critcl::include for easy inclusion of headers and other C
files.
[3] New command critcl::make to generate a local header of other C files for use by
other parts of a package through inclusion.
[4] New utility package critcl::literals for quick and easy setup of and access to
pools of fixed Tcl_Obj* strings. Built on top of critcl::iassoc.
[5] New utility package critcl::bitmap for quick and easy setup and use of mappings
between C bitsets and Tcl lists whose string elements represent that set. Built on
top of critcl::iassoc.
CHANGES FOR VERSION 3.1.10
[1] Fixed code version numbering forgotten with 3.1.9.
[2] Fixed issue #35. In package mode (-pkg) the object cache directory is unique to the
process, thus we do not need content-hashing to generate unique file names. A
simple counter is sufficient and much faster.
Note that mode "compile & run" is not as blessed and still uses content-hasing with
md5 to ensure unique file names in its per-user object cache.
[3] Fixed issue where the ccommand forgot to use its body as input for the UUID
generation. Thus ignoring changes to it in mode compile & run, and not rebuilding a
library for changed sources. Bug and fix reported by Peter Spjuth.
CHANGES FOR VERSION 3.1.9
[1] Fixed issue #27. Added missing platform definitions for various alternate linux and
OS X targets.
[2] Fixed issue #28. Added missing -mXX flags for linking at the linux-{32,64}-*
targets.
[3] Fixed issue #29. Replaced the use of raw "cheaders" information in the processing
of "cdefines" with the proper include directives derived from it.
[4] Fixed the issue behind rejected pull request #30 by Andrew Shadura. Dynamically
extract the stubs variable declarations from the Tcl header files and generate
matching variable definitions for use in the package code. The generated code will
now be always consistent with the headers, even when critcl's own copy of them is
replaced by system headers.
[5] Fixed issue #31. Accepted patch by Andrew Shadura, with changes (comments), for
easier integration of critcl with OS package systems, replacing critcl's copies of
Tcl headers with their own.
[6] Fixed issue #32. Merged pull request by Andrew Shadura. Various typos in
documentation and comments.
[7] Fixed issue #34. Handle files starting with a dot better.
CHANGES FOR VERSION 3.1.8
[1] Fixed issue with package indices generated for Tcl 8.4. Join the list of commands
with semi-colon, not newline.
[2] Fixed issue #26 which brought up use-cases I had forgotten to consider while fixing
bug #21 (see critcl 3.1.6).
CHANGES FOR VERSION 3.1.7
[1] Fixed issue #24. Extract and unconditionally display compiler warnings found in the
build log. Prevents users from missing warnings which, while not causing the build
to fail, may still indicate problems.
[2] New feature. Output hook. All non-messaging user output is now routed through the
command critcl::print, and users are allowed to override it when using the critcl
application-as-package.
[3] New feature, by Ashok P. Nadkarni. Platform configurations can inherit values from
configurations defined before them.
CHANGES FOR VERSION 3.1.6
[1] Fixed issue #21. While the multi-definition of the stub-table pointer variables was
ok with for all the C linkers seen so far C++ linkers did not like this at all.
Reworked the code to ensure that this set of variables is generated only once, in
the wrapper around all the pieces to assemble.
[2] Fixed issue #22, the handling of the command identifier arguments of
critcl::ccommand, critcl::cproc, and critcl::cdata. We now properly allow any Tcl
identifier and generate proper internal C identifiers from them.
As part of this the signature of command critcl::name2c changed. The command now
delivers a list of four values instead of three. The new value was added at the
end.
Further adapted the implementation of package critcl::class, a user of
critcl::name2c. This package is now at version 1.0.6 and requires critcl 3.1.6
Lastly fixed the mis-handling of option -cname in critcl::ccommand, and
critcl::cproc.
[3] Fixed issue #23.
CHANGES FOR VERSION 3.1.5
[1] Fixed issue #19. Made the regular expression extracting the MSVC version number
more general to make it work on german language systems. This may have to be
revisited in the future, for other Windows locales.
[2] Fixed issue #20. Made option -tea work on windows, at least in a unix emulation
environment like msys/mingw.
CHANGES FOR VERSION 3.1.4
[1] Bugfix in package critcl::class. Generate a dummy field in the class structure if
the class has no class variables. Without this change the structure would be empty,
and a number of compilers are not able to handle such a type.
[2] Fixed a typo which broke the win64 configuration.
[3] Fixed issue #16, a typo in the documentation of command critcl::class.
CHANGES FOR VERSION 3.1.3
[1] Enhancement. In detail:
[2] Added new argument type "pstring", for "Pascal String", a counted string, i.e. a
combination of string pointer and string length.
[3] Added new methods critcl::argtypesupport and ::critcl::argsupport to define and use
additional supporting code for an argument type, here used by "pstring" above to
define the necessary structure.
[4] Semi-bugfixes in the packages critcl::class and critcl::iassoc. Pragmas for the AS
meta data scanner to ensure that the template files are made part of the package.
Versions bumped to 1.0.4 and 1.0.1 respectively.
CHANGES FOR VERSION 3.1.2
[1] Enhancement. In detail:
[2] Extended critcl::cproc to be able to handle optional arguments, in a limited way.
This is automatically available to critcl::class cproc-based methods as well.
[3] Bugfix in lassign emulation for Tcl 8.4. Properly set unused variables to the
empty string. Bumped version of emulation package lassign84 to 1.0.1.
CHANGES FOR VERSION 3.1.1
[1] Bugfixes all around. In detail:
[2] Fixed the generation of wrong#args errors for critcl::cproc and derived code
(critcl::class cproc-based methods). Use NULL if there are no arguments, and take
the offset into account.
[3] Fixed the handling of package names by critcl::class. Forgot that they may contain
namespace separators. Bumped to version 1.0.1.
[4] Extended a critcl::class generated error message in instance creation for clarity.
Bumped to version 1.0.2.
CHANGES FOR VERSION 3.1
[1] Added a new higher-level package critcl::iassoc.
This package simplifies the creation of code associating data with an interpreter
via Tcl's Tcl_(Get|Set)AssocData() APIs. The user can concentrate on his data while
all the necessary boilerplate C code to support this is generated by the package.
This package uses several of the new features which were added to the core critcl
package, see below.
[2] Added the higher-level package critcl::class.
This package simplifies the creation of C level objects with class and instance
commands. The user can write a class definition with class- and instance-variables
and -methods similar to a TclOO class, with all the necessary boilerplate C code to
support this generated by the package.
This package uses several of the new features which were added to the core critcl
package, see below.
[3] Extended the API for handling TEApot metadata. Added the command critcl::meta? to
query the stored information. Main use currently envisioned is retrieval of the
current package's name by utility commands, for use in constructed names. This
particular information is always available due to the static scan of the package
file on execution of the first critcl command.
The new packages critcl::iassoc and critcl::class (see above) are users of this
command.
[4] Extended the API with a command, critcl::name2c, exposing the process of converting
a Tcl name into base name, namespace, and C namespace. This enables higher-level
code generators to generate the same type of C identifiers as critcl itself.
The new package critcl::class (see above) is a user of this command.
[5] Extended the API with a command, critcl::source, executing critcl commands found in
a separate file in the context of the current file. This enables easier management
of larger bodies of code as it allows the user to split such up into easier to
digest smaller chunks without causing the generation of multiple packages.
[6] Related to the previous item, extended the API with commands to divert collection
of generated C code into memory. This makes it easier to use the commands for
embedded C code in higher-level code generators.
See the section Advanced: Diversions for details of the provided commands.
The new package critcl::class (see above) is a user of these facilities.
[7] Extended the API with commands helping developers with the generation of proper C
#line directives. This allows higher-level code generators to generate and insert
their own directives, ensuring that compile errors in their code are properly
attributed.
See the section Advanced: Location management for details of the provided commands.
The new packages critcl::iassoc and critcl::class (see above) are users of these
facilities.
[8] Extended the API with commands giving users the ability to define custom argument
and result types for ::critcl::cproc.
See the section Advanced: Extending cproc for details of the provided commands.
CHANGES FOR VERSION 3.0.7
[1] Fixed the code generated by critcl::c++command. The emitted code handed a non-
static string table to Tcl_GetIndexFromObj, in violation of the contract, which
requires the table to have a fixed address. This was a memory smash waiting to
happen. Thanks to Brian Griffin for alrerting us to the general problem.
CHANGES FOR VERSION 3.0.6
[1] Fixed github issue 10. The critcl application now delivers a proper exit code (1)
on build failure, instead of always indicating success (status 0).
[2] Fixed github issue 13. Handling of bufferoverflowU.lib for release builds was
inconsistent with handling for debug builds. It is now identically handled
(conditional) by both cases.
[3] Documentation cleanup, mainly in the installation guide, and the README.md shown by
github
CHANGES FOR VERSION 3.0.5
[1] Fixed bug in the new code for #line pragmas triggered when specifying C code
without leading whitespace.
[2] Extended the documentation to have manpages for the license, source retrieval,
installer, and developer's guides.
CHANGES FOR VERSION 3.0.4
[1] Fixed generation of the package's initname when the incoming code is read from
stdin and has no proper path.
[2] Fixed github issue 11. Now using /LIBPATH instead of -L on Windows (libinclude
configuration setting).
[3] Extended critcl to handle -l:path format of -l options. GNU ld 2.22+ handles this
by searching for the path as is. Good when specifying static libraries, as plain -l
looks for shared libraries in preference over static. critcl handles it now, as
older GNU ld's do not understand it, nor the various vendor-specific linkers.
[4] Fixed github issue #12. Critcl now determines the version of MSVC in use and uses
it to switch between various link debug options. Simplified the handling of
bufferoverflowU.lib also, making use of the same mechanism and collapsing the two
configurations sections we had back into one.
[5] Reworked the insertion of #line pragmas into the generated C code to avoid
limitations on the line number argument imposed by various compilers, and be more
accurate.
[6] Modified argument processing. Option -libdir now also implies -L for its argument.
[7] Extended handling of option -show (critcl::showconfig) to list the path of the
configuration file the data is coming from. Good for debugging configuration
processing.
[8] Extended the build script with targets to regenerate the embedded documentation,
and diagrams, and to generate a release.
CHANGES FOR VERSION 3.0.3
[1] Fixed github issues 5 and 8, for the example build.tcl scripts. Working around a
missing variable ::errorInfo. It should always be present, however there seem to be
revisions of Tcl around which violate this assumption.
CHANGES FOR VERSION 3.0.2
[1] Fixed issue in compile-and-run mode where commands put into the auto_index are not
found by Tcl's [unknown] command.
[2] Fixed an array key mismatch breaking usage of client data and delete function for
procedure. Reported by Jos DeCoster, with patch.
[3] Implemented a command line option -L, an equivalent of option -I, just for library
search paths.
[4] Fixed github issues 5 and 8. Working around a missing variable ::errorInfo. It
should always be present, however there seem to be revisions of Tcl around which
violate this assumption.
CHANGES FOR VERSION 3.0.1
[1] Bugfixes all around. In detail:
[2] Fixed recording of Tcl version requirements. Keep package name and version
together, unbreaking generated meta data and generated package load command.
[3] Fixed the build scripts: When installing, or wrapping for TEA, generate any missing
directories
[4] Modified the build scripts to properly exit the application when the window of
their GUI is closed through the (X) button.
[5] Removed an 8.5-ism (open wb) which had slipped into the main build script.
[6] Modified the example build scripts to separate the output for the different
examples (and packages) by adding empty lines.
[7] stack::c example bugfix: Include API declarations for use in the companion files.
[8] Extended the documentation: Noted the need for a working installation of a C
compiler.
[9] Extended the Windows target definitions and code to handle the manifest files used
by modern MS development environments. Note that this code handles both
possibilities, environment using manifests, and (old(er)) environments without.
[10] Extended the Windows 64bit target definitions and code to auto-detect the need for
the helper library "bufferoverflowU.lib" and reconfigure the compile and link
commands appropriately. We assume that the library must be linked when present.
This should be no harm if the library is present, yet not needed. Just superfluous.
We search for the library in the paths specified by the environment variable LIB.
CHANGES FOR VERSION 3
[1] The command critcl::platform was deprecated in version 2.1, superceded by
critcl::targetplatform, yet kept for compatibility. Now it has been removed.
[2] The command critcl::compiled was kept with in version 2.1 with semantics in
contradiction to its, for compatibility. This contradiction has been removed,
changing the visible semantics of the command to be in line with its name.
[3] The change to version 3 became necessary because of the two incompatible visible
changes above.
[4] Extended the application package with code handling a new option -tea. Specifying
this option invokes a special mode where critcl generates a TEA package, i.e. wraps
the input into a directory hierarchy and support files which provide it TEA-
lookalike buildsystem.
This new option, and -pkg, exclude each other. If both are specified the last used
option takes precedence.
The generated package directory hierarchy is mostly self-contained, but not fully.
It requires not only a working installation of Tcl, but also working installations
of the packages md5 and cmdline. Both of these are provided by the Tcllib bundle.
Not required, but recommended to have installed are any of the packages which can
accelerate md5's operation, i.e. cryptkit, tcllibc, or Trf.
[5] Extended the critcl package with a new command critcl::scan taking the path to a
".critcl" file, statically scanning it, and returning license, version, a list of
its companion files, list of imported APIs, and list of developer-specified custom
configuration options. This data is the foundation for the TEA wrapping described
above.
Note that this is a static scan. While the other build modes can (must) execute the
".critcl" file and make platform-specific decisions regarding the assembled C code,
companion files, etc. the TEA wrap mode is not in a position to make platform-
specific decisions. It has to wrap everything which might conceivably be needed
when actually building. Hence the static scan. This has however its own set of
problems, namely the inability to figure out any dynamic construction of companion
file paths, at least on its own. Thus:
[6] Extended the API used by critcl-based packages with the command critcl::owns. While
this command is ignored by the regular build modes the static scanner described
above takes its arguments as the names of companion files which have to be wrapped
into the TEA package and could not be figured by the scanner otherwise, like
because of dynamic paths to critcl::tsources, critcl::csources, getting sourced
directly, or simply being adjunct datafiles.
[7] Extended the API used by critcl-based packages with the command critcl::api for the
management of stubs tables, be it their use, and/or declaration and export.
Please see section Stubs Table Management of the critcl package documentation for
details.
[8] Extended the API used by critcl-based packages with the command critcl::userconfig
for the management of developer-specified custom configuration options, be it their
use and/or declaration.
Please see section Custom Build Configuration of the critcl package documentation
for details.
[9] Extended the API used by critcl-based packages with the commands
critcl::description, critcl::summary, critcl::subject, critcl::meta, and
critcl::buildrequirement for the declaration of TEApot meta data for/about the
package.
Please see section Package Meta Data of the critcl package documentation for
details.
CHANGES FOR VERSION 2.1
[1] Fixed bug where critcl::tsources interpreted relative paths as relative to the
current working directory instead of relative to the ".critcl" file using the
command, as all other commands of this type do.
[2] Fixed internals, preventing information collected for multiple ".critcl" files to
leak between them. Notably, critcl::tk is not a global configuration option
anymore.
[3] Fixed the command critcl::license to be a null-operation in mode "compile & run",
instead of throwing an error.
[4] Fixed the critcl application's interference with the "compile & run" result cache
in -pkg mode by having it use a wholly separate (and by default transient)
directory for that mode.
[5] Fixed bug where changes to a ".critcl" file did not result in a rebuild for mode
"compile & run". All relevant API commands now ensure UUID changes.
[6] Fixed bug in the backend handling of critcl::debug where the companion c-sources of
a ".critcl" file were not compiled with debug options, although the ".critcl" file
was.
[7] Fixed bug in critcl::debug which prevented recognition of mode "all" when it was
not the first argument to the command.
[8] Fixed bug in "preload.c" preventing its compilation on non-windows platforms.
[9] Fixed long-standing bug in the handling of namespace qualifiers in the command name
argument of critcl::cproc and critcl::ccommand. It is now possible to specify a
fully qualified command name without issues.
[10] Extended/reworked critcl::tsources to be the canonical way of declaring ".tcl"
companion files even for mode "compile & run".
[11] Extended/reworked critcl::tsources to allow the use of a ".critcl" file as its own
Tcl companion file.
[12] Extended critcl::framework to internally check for OS X build target, and to ignore
the declaration if its not.
[13] Extended critcl::failed to be callable more than once in a ".critcl" file. The
first call forces the build, if it was not done already, to get the result. Further
calls return the cached result of the first call.
[14] Extended the handling of environment variable CC in the code determining the
compiler to use to deal with (i.e. remove) paths to the compiler, compiler file
extensions, and compiler options specified after the compiler itself, leaving only
the bare name of the compiler.
[15] Extended the code handling the search for preloaded libraries to print the paths it
searched, making debugging of a search failure easier.
[16] A new command critcl::tcl can be used to declare the version of Tcl minimally
needed to build and run the ".critcl" file and package. Defaults to 8.4 if not
declared. Extended critcl to have the stubs and headers for all of Tcl 8.4, 8.5,
and 8.6.
[17] A new command critcl::load forces the build and load of a ".critcl" file. This is
the official way for overriding critcl's default lazy-build-&-load-on-demand scheme
for mode "compile & run".
Note that after using critcl::load / critcl::failed in a ".critcl" file it is not
possible to use critcl commands in that file anymore. Doing so will throw an error.
[18] Extended the generation of '#line' pragmas to use info frame (if available) to
provide the C compiler with exact line numbers into the ".critcl" file for the
reporting of warnings and errors.
[19] Extended critcl::check with logging to help with debugging build-time checks of the
environment, plus an additional optional argument to provide labeling.
[20] Added a new command critcl::checklink which not only tries to check the environment
via compiling the code, but also its linkability.
[21] Added a new command critcl::msg for messaging, like command critcl::error is for
error reporting. Likewise this is a hook a user of the package is allowed to
override. The default implementation, used by mode compile & run does nothing. The
implementation for mode generate package prints the message to stdout.
Envisioned use is for the reporting of results determined by critcl::check and
critcl::checklink during building, to help with debugging when something goes wrong
with a check.
[22] Exposed the argument processing internals of critcl::proc for use by advanced
users. The new commands are
[1] critcl::argnames
[2] critcl::argcnames
[3] critcl::argcsignature
[4] critcl::argvardecls
[5] critcl::argconversion
Please see section Advanced Embedded C Code of the critcl package documentation for
details.
[23] Extended the critcl package to intercept package provide and record the file ->
package name mapping. Plus other internal changes now allow the use of namespaced
package names while still using proper path names and init function.
[24] Dropped the unused commands critcl::optimize and critcl::include.
[25] Dropped -lib mode from the critcl application.
[26] Dropped remnants of support for Tcl 8.3 and before.
AUTHORS
Jean Claude Wippler, Steve Landers, Andreas Kupries
BUGS, IDEAS, FEEDBACK
This document, and the package it describes, will undoubtedly contain bugs and other
problems. Please report them at https://github.com/andreas-kupries/critcl/issues. Ideas
for enhancements you may have for either package, application, and/or the documentation
are also very welcome and should be reported at https://github.com/andreas-
kupries/critcl/issues as well.
KEYWORDS
C code, Embedded C Code, code generator, compile & run, compiler, dynamic code generation,
dynamic compilation, generate package, linker, on demand compilation, on-the-fly
compilation
CATEGORY
Glueing/Embedded C code
COPYRIGHT
Copyright (c) Jean-Claude Wippler
Copyright (c) Steve Landers
Copyright (c) 2011-2018 Andreas Kupries