critcl(3tcl)

💖 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, aka CriTcl, is a whole system for compiling C code that's embedded inside your Tcl — on the fly — and then either loading the resulting objects straight into Tcl so you can use them immediately, or packaging them up for distribution. Bestie, the whole point is performance: you rewrite the routines that are your bottleneck in C, and suddenly everything slaps. 💅

The critcl package is the core of the system. If you want the big-picture tour of the entire thing, go read Introduction To CriTcl. If you want to know how to use the standalone critcl program, that's CriTcl Application. This core package is the one you use to embed C code into Tcl scripts. It also hands you access to the internals that other parts of the core lean on — which is genuinely interesting if you wanna understand how the core works under the hood, and how the API it gives to the CriTcl Application works. Those advanced bits are marked as advanced, so if you're just here to use the package, you can skip right past them. 🦋

This package lives in the Core Package Layer of CriTcl.

+----------------+
|Applications    |
| critcl         |
| critcl::app    |
+----------------+

*================*
|Core Packages   |
| critcl         |
| critcl::util   |
*================*

+----------------+
|Support Packages|
| stubs::*       |
| md5, platform  |
|  ...           |
+----------------+

---

👑 API 👑

Tiny heads-up before we dive in: instead of saying "a Tcl script with embbedded C code" or "a Tcl script containing Critcl commands" over and over (so tedious 😭), we're just gonna call that kind of script a Critcl script. And a file holding a Critcl script usually has the extension .tcl or .critcl. Periodt. ✨

---

🧚 EMBEDDED C CODE 🧚

These commands all append C code fragments to the current module. Fragments show up in the module in the exact order you appended them — so earlier fragments (variables, functions, macros, whatever) are visible to the later ones. Order matters, no cap. 💜

::critcl::ccode fragment

Appends the C code in fragment to the current module, and returns the empty string. Peep Runtime Behaviour. 🌈

---

::critcl::ccommand tclname cname

Same as documented below, except that cname is the name of a C function that already exists. Easy. 😌

---

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

Appends the code that creates a Tcl command named tclname plus a matching C function whose body is body, behaving exactly as documented for Tcl's own Tcl_CreateObjCommand (https://www.tcl-lang.org/man/tcl/TclLib/CrtObjCmd.htm). 🔥

arguments is a list of zero to four names for the standard arguments clientdata, interp, objc, and objv. Any names you leave out get the standard default names instead. This is a more low-level way to define a command than critcl::cproc, because processing of the items in objv is left entirely to you — giving you complete control over how the command's arguments get handled. 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. Defaults to NULL.
• -delproc c-expression — Provides a function pointer of type Tcl_CmdDeleteProc (https://www.tcl-lang.org/man/tcl/TclLib/CrtObjCmd.htm) to be the deletion function for the new command. Defaults to NULL.
• -cname boolean — If false (the default), a name for the corresponding C function is automatically derived from the fully-qualified tclname. Otherwise, the 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. The value can be a C macro, or a function call (parentheses included, bestie) to any visible C function that takes no 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 no C function gets 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 list of glob patterns to be created in the namespace namespace, each variable having the same name as the corresponding C item. The default namespace is the global namespace. A pattern that matches nothing gets ignored. 🙈

The Tcl variables are created when the module is compiled, using the preprocessor so it can properly find all the matching C definitions.

Produces no C code. The C definitions you want must already exist.

---

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

Appends a function having body as its body, plus another shim function to do the needed conversions, plus the code to create a corresponding Tcl command named tclname. Unlike critcl::ccommand, the arguments and the 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.

Each option is a 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, the name of the C function is the last component of tclname.
• -pass-cdata boolean — If false (the default), the shim function that performs the conversion to and from the 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 aren't directly seen by the function but which influence argument counting and extraction. 🧠

okay bestie, so string resulttype is literally the type of the result your C function hands back. It can be one of the predefined types below, or a custom one you cooked up (for that, go see Advanced: Extending cproc). Unless the notes say otherwise, the Tcl return code is always TCL_OK. Before we get into the nitty-gritty, here's the quick-and-dirty overview, no cap:

• void — C type: n/a · Tcl type: n/a · Notes: Always OK. Body sets result.
• ok — C type: int · Tcl type: n/a · Notes: Result code. Body sets result.

---

• int — C type: int · Tcl type: Int
• boolean — Alias of int above
• bool — Alias of int above
• long — C type: long · Tcl type: Long
• wideint — C type: Tcl_WideInt · Tcl type: WideInt
• double — C type: double · Tcl type: Double
• float — C type: float · Tcl type: Double

---

• char* — C type: char* · Tcl type: String · Notes: Makes a copy
• vstring — Alias of char* above
• const char* — Behavior of char* above

---

• string — Tcl type: String · Notes: 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* — C type: Tcl_Obj* · Tcl type: Any · Notes: refcount --
• object — Alias of Tcl_Obj* above
• Tcl_Obj*0 — Tcl type: Any · Notes: refcount unchanged
• object0 — Alias of Tcl_Obj*0 above

---

• known-channel — C type: Tcl_Channel · Tcl type: String · Notes: Assumes to already be registered
• new-channel — C type: Tcl_Channel · Tcl type: String · Notes: New channel, will be registered

And now the details:

💖 Tcl_Obj* / object 💖

If your returned Tcl_Obj* is NULL, the Tcl return code is TCL_ERROR, and your function should set an error mesage [https://www.tcl-lang.org/man/tcl/TclLib/SetResult.htm] as the interpreter result. Otherwise, that returned Tcl_Obj* gets set as the interpreter result. Periodt.

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.

Also note: the returned Tcl_Obj* should have a reference count greater than 0. Why? Because the converter decrements the reference count to release possession after setting the interpreter result. It assumes your function incremented the reference count of the returned Tcl_Obj*. If you returned a Tcl_Obj* with a reference count of 0, 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 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:

okay bestie gather round, here's the whole type cheat-sheet in one glorious glance 🌈 left column is the critcl type you actually write, middle is the C type that lands in your function signature, right is the Tcl type it maps to, and the notes are where the drama lives 💅

• Tcl_Interp* → C type: Tcl_Interp*, Tcl type: n/a — special, only first
• Tcl_Obj* → C type: Tcl_Obj*, Tcl type: Any — read-only
• object — alias of Tcl_Obj* above
• list → C type: critcl_list, Tcl type: List — read-only
• char* → C type: const char*, Tcl type: Any — read-only, string rep
• pstring → C type: critcl_pstring, Tcl type: Any — read-only
• bytes → C type: critcl_bytes, Tcl type: ByteArray — read-only
• int → C type: int, Tcl type: Int
• long → C type: long, Tcl type: Long
• wideint → C type: Tcl_WideInt, Tcl type: WideInt
• double → C type: double, Tcl type: Double
• float → C type: float, Tcl type: Double
• X > 0, X >= 0, X < 0, X <= 0, X > 1, X >= 1, X < 1, X <= 1 — for X in int ... float above. C types are as per the base type X. Allowed argument values are restricted as per the shown relation. This is not a general mechanism open to other values. Only 0/1. 🙅‍♀️
• boolean → C type: int, Tcl type: Boolean
• bool — alias of boolean above
• bytearray — DEPRECATED
• rawchar — DEPRECATED
• rawchar* — DEPRECATED
• double* — DEPRECATED
• float* — DEPRECATED
• int* — DEPRECATED
• void* — DEPRECATED

---

✨ and now the deets ✨

• Tcl_Interp* — ⚠️ attention bestie, this one is SPECIAL. 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 you do use it, the argument will contain a reference to the current interpreter that the function body may use. And here's the plot twist: the argument will not be an argument of the Tcl command for the function. It's useful when the function has to do more than simply returning a value — like 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. 💀 like fr, don't touch it.

• 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. 🫠 same energy as above, bestie.

• 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. (yes, we're saying it again, it's that serious) 🦋
• 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 interpreter 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 empty 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". 🏃‍♀️

So in "generate package" mode, -includedir is the girl who decides which subdirectory inside the package the generated headers get dropped into 💅. That directory gets added to the search paths for header files, which means a package that's importing an API will actually find it — as long as the package exporting that API used the same -includedir setting. synergy!! ✨

And in "generate TEA" mode? The static scanner recognizes critcl::api header as a source of companion files, periodt. It also takes the data from calls to critcl::api import and uses it to add support for --with-foo-include options into the generated "configure(.in)", so a user can specify custom locations for the headers of any imported API. bespoke header locations, we love to see it 🎀

---

🎀 PACKAGE META DATA 🎀

Critcl versions 3 and later can create TEApot meta-data to be placed into "teapot.txt", in a format that's suitable for use by the TEApot tools (http://docs.activestate.com/activetcl/8.5/tpm/toc.html). okayyy fancy metadata era 💖

Back in version 2, some meta data support was already hanging around through ::critcl::license, but bestie it was only ever used to generate "license.txt". that's it. that was the whole job. 🙈

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

Ignored in "compile & run" mode. (not invited to that party 💀)

In "generate package" mode it provides information about the author of the package and the license for the package.

The text arguments get 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. either way, it's giving paperwork ✨

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 it 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. short and sweet, like a good bio 🦋

• ::critcl::description text

Ignored in "compile & run" mode.

In "generate package" mode it 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. the extended cut, the director's commentary, the whole vibe 🌸

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

Ignored in "compile & run" mode.

In "generate package" mode it 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. stack 'em up bestie 👑

• ::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. like, you can say it, but nobody's writing it down 🚫

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. no notes, it does it for you 💅

• ::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. ✨ selective memory, iconic

---

🌈 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". no cross-contamination, we keep our business our business 💖

• ::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. yes you have to do it yourself, sorry bestie 😭

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. order matters, don't shuffle 🎀

• ::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. yes this is the "hey, don't forget about these ones" command 🫶

• ::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. write it once, forget it 💅

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. iykyk 🔥

• ::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. go big or go home ⭐

---

🔍 INTROSPECTION 🔍

The following commands control compilation and linking.

• ::critcl::check ?label? text — hands you back true when the C code sitting in text compiles all nice and clean, and false when it doesn't. It's the vibe-check for "does this build environment even have that feature tho". If you pass a label, it gets used to uniquely tag the results over in the generated log. 💅
• ::critcl::checklink ?label? text — literally critcl::check's sibling but it also links the compiled objects, returning true if the link goes through and false if it flops. Same deal with label if you give one: it uniquely marks the results in the generated log. 🔗
• ::critcl::msg ?-nonewline? msg — this is what scripts leaning on critcl::check and critcl::checklink use to report their results back. In compile & run mode it does, like, absolutely nothing. Tools such as the CriTcl Aplication are free to redefine it and do their own message-reporting thing. Case in point: critcl::app — and any packages built on top of it — print messages straight to stdout. 📢
• ::critcl::print ?-nonewline? ?chan? msg — the Critcl internals use this one to report activity. By default it's effectively the same thing as ::puts. Tools that go straight to either the Critcl package or the Critcl application package may redefine this procedure so they can implement their own output functionality. 🖨️

For example, the newest revisions of Kettle (https://chiselapp.com/user/andreas_kupries/repository/Kettle/index) use it to highlight build warnings. ✨

• ::critcl::compiled — returns true when the current Critcl script is already compiled, false otherwise.

It lets a Critcl script that's doubling as its own Tcl companion file (peep critcl::tsources) tell the difference between being sourced for compilation in compile & run mode, versus being sourced from either the output 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 other two. 🦋

• ::critcl::compiling — true if there's a working C compiler available, false if not. Simple as. 🌸
• ::critcl::done — true once the Critcl script has been built, false otherwise. Only useful from inside a Critcl script. It's how the Tcl parts of a Critcl script can tell prebuilt package mode apart from compile & run mode. 🎀

See also Modes Of Operation/Use.

• ::critcl::failed — true if the Critcl script could not be built, false otherwise. It forces the building of the package if that hasn't happened yet — but not its loading. So a Critcl script can check itself for whether the compiled components are available. Only useful from inside a Critcl script. 😤
• ::critcl::load — same energy as critcl::failed, except it also forces the loading of the generated shared library, and it flips the return around: true on success, false on failure. So again, a Critcl script can check itself for availability of the compiled components. Only useful from inside a Critcl script. 🔥

---

🌈 BUILD MANAGEMENT 🌈

This next command wrangles the global settings — as in, the configuration options that are totally independent of any one Critcl script.

ngl bestie, you should not need this to write a Critcl script. It's a management command, and it's only actually 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 don't get built if there's already a cached shared library.
  • lines bool — when true (the default), #line directives get embedded into the generated C code.

This facility needs a tclsh that provides info frame — otherwise no #line directives are emitted at all. The command is supported by Tcl 8.5 and higher. It's also supported by Tcl 8.4 as long as it was compiled with the define -DTCL_TIP280. An example of such a thing is ActiveState's ActiveTcl.

Devs of higher-level packages that generate their own C code — whether directly or indirectly through critcl — should also read the section Advanced: Location management to see how critcl helps them generate their directives. Examples of such packages ship 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 gets inserted. Inserting that kind of 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 is object files usable for static linking into a big shell.
• language string
• keepsrc bool — when false (the default), the generated ".c" files get deleted after the ".o" files have been built. 🗑️
• outdir directory — the directory where the generated shared library goes. By default, it lands in the Result Cache.

---

🧚 RESULT CACHE MANAGEMENT 🧚

These commands are in charge of the Result Cache. And again — you do not need them to just 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 it usually doesn't need any changing. 🏠

• ::critcl::clean_cache ?pattern...? — cleans the result cache, i.e. yeets any and all files and directories inside it. If you hand it one or more patterns, then only the files and directories matching them get removed. 🧹

---

💅 BUILD CONFIGURATION 💅

These commands manage the build configuration — meaning the per-platform info about compilers, linkers, and all their commandline options. And yes: not needed to just write a Critcl script. 😌

• ::critcl::readconfig path — reads the build configuration file at path and configures the package using the info for the target platform.
• ::critcl::showconfig ?chan? — converts the active build configuration into a human-readable string and returns it — or, if chan is given, prints the result to that channel. 📺
• ::critcl::showallconfig ?chan? — converts the whole 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 given, prints it to that channel.
• ::critcl::chooseconfig target ?nomatcherr? — matches target against all known targets, returning a list of all the ones that match. The search runs on an exact basis first, then via glob matching. If no known target matches the argument, the default is to return an empty list. But if the boolean nomatcherr is specified and set, an error gets thrown using critcl::error instead. 😱
• ::critcl::setconfig target — configures the package to use the settings of target.

---

👑 TOOL API 👑

These commands give tools like the CriTcl Application (or similar) deeper access to the package's internals. And, one more time for the people in the back — you do not need them to just 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 info resolved. 🎯
• ::critcl::buildforpackage ?flag? — signals whether the next file is to be built for inclusion into a package. If you don't specify it, flag defaults to true, i.e. building for a package. This disables a bunch of things in the backend, namely the linking of that file into a shared library and the loading of that library. The expectation is that the build results get wrapped into a larger collection later. 📦
• ::critcl::cnothingtodo file — checks whether there's anything to build for file.
• ::critcl::cresults ?file? — returns info about building file, or about info script if file isn't provided. The result is a dictionary holding these 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, so it can 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 successfully load and use file.
  • tk — true if file requires Tk, 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 — figures out whether the package is configured for cross-compilation, and if so prints a message to the standard error channel. ⚠️
• ::critcl::error msg — used to report internal errors. The default implementation just returns the error. Tools like the CriTcl Application are allowed to redefine this procedure and do their own error-reporting thing. There's exactly one constraint they can't break: 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

bestie this one is so simple it's almost a nap. it hands you back the file extension that shared libraries get on the target platform. that's the whole thing. 💅

::critcl::targetconfig

returns the identifier of the target you're building for — exactly as it was specified by either the user or the system, whoever got there first. 🎯

::critcl::buildplatform

returns the identifier of the build platform, which is fancy-speak for "where the package is actually running". the machine you're sitting at, basically. 🖥️

::critcl::targetplatform

returns the identifier of the target platform — the platform you're compiling for. and lowkey this is the fun one, because unlike ::critcl::actualtarget, this one may be the name of a cross-compilation target. so it might not be where you're standing at all. ✈️

::critcl::cobjects ?glob pattern...?

it's giving ::critcl::clibraries, but make it object files. instead of matching libraries, each glob pattern matches object files to be linked into the shared object — and no cap, this happens at compile time, not runtime. ⏰

if a glob pattern matches literally nothing, you get an error. no silent vibes here.

not listed in Control & Interface because it is of no use to package writers. only tools like the CriTcl Application need it. iykyk.

a pattern for a relative path gets resolved relative to the directory containing the Critcl script. 📁

calls to this command are cumulative. stack 'em up, bestie.

::critcl::scan path

this is 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 buildsystem, etc. very behind-the-scenes, very main character. 🌟

it 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

give it the Tcl-level identifier name, and it 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 exactly this. 🧚

---

🧚 ADVANCED: EMBEDDED C CODE 🧚

for the advanced girlies: the following commands, which are 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. one command. she's efficient. 💅

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

this command defines a 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 is 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 options 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 it's totally 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. so set away, bestie, it just might not matter. 🙈

---

🦋 ADVANCED: LOCATION MANAGEMENT 🦋

first, a small intro for anyone asking themselves "what even 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. so when the compiler yells, it yells about your file. iconic. 🔥

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 bugs 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. 8️⃣

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, but 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 line endings found in the strings. 🔢

::critcl::at::caller!

::critcl::at::caller! offset

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

okay so these three get listed with no description attached in the original — it just drops them here and then stops. i'm not about to make up lore, so: here they are, exactly as listed. 💀

✨ ::critcl::at::here! ✨

Okay bestie these ones are the combo meal 🍓 — they're just caller and here glued together with get. So they stash the location and immediately hand it back to you, already formatted as a proper #line directive. Chef's kiss. 💅

Heads up though: once you use one of these, the stored location gets cleared. It's a one-shot, no leftovers. 🫶

---

💖 ADVANCED: DIVERSIONS 💖

So diversions are the high-level package girlies' tool — for people writing their own C code generators who want to make critcl's Embedded C Code commands easier to wield. 👑

Here's the vibe: these commands normally dump all their C code into the current .critcl file, and sometimes that's just not what a bigger package wants. Rude, honestly.

With a diversion, the generator output gets redirected into memory instead, and from there you can handle it, poke at it, process it however you like, and then commit it to an actual .c file. Main character energy. ✨

There's a real example of this shipping with critcl itself — go peek at the implementation of package critcl::class. 💜

To help those devs out, three commands exist for managing diversions and the in-memory C code collection. Behold:

::critcl::collect_begin

This one kicks off the diversion — C code collection goes into memory. 🌀

The result of the command is the empty string.

You can call it multiple times, and each call opens a new nesting level of diversion. Layers on layers, no cap.

::critcl::collect_end

Ends 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. Just the top one, bestie.

The command throws an error if no diversion is active — that's the system telling you your collect_begin and collect_end pairing is mismatched. 😭

::critcl::collect script

The convenience queen 👑 — runs the script under diversion and returns the collected C code, making sure collect_begin and collect_end are correctly paired for you. You're welcome.

---

🌈 ADVANCED: FILE GENERATION 🌈

Okay so this is related to diversions from the section above, but it is not the same thing. Not even a little. 🙅‍♀️ That said, like diversions, it's for the higher-level packages generating their own C code.

Three examples of utility packages using this facility come bundled with critcl itself — go read the implementations of packages critcl::literals, critcl::bitmap, and critcl::enum. 📚

Here's the situation: when you split a package implementation into pieces, it's often very sensible to have a bunch of pure C companion files holding low-level code. But those files might need info about the code in the main .critcl file. And normally those declarations aren't exportable, and using the stub table support makes zero sense because this is all completely internal to the package. Internal business only. 🤫

So with the file generation command below, the main .critcl file can generate any number of header files for the C companions to pick up. Iconic. ✨

::critcl::make path contents

Creates the file path in a location where the C companion files of the package can grab it by simply including path during their compilation — and it doesn't interfere with the outer system at all. Zero drama, zero side effects. 🧚

The generated file will contain the specified contents.

---

🎀 ADVANCED: EXTENDING CPROC 🎀

critcl::cproc gets the most common C types (peep the section Embedded C Code), but sometimes that's just... not enough. 😤

So to get around that limitation, the commands in this section let critcl users extend the set of argument and result types that critcl::cproc understands. In other words: define your own custom types, bestie. Make them yours. 💅

::critcl::has-resulttype name

Tests whether the named result-type is known or not. Returns a boolean value — true if the type is known, false otherwise. Simple as. ✅

::critcl::resulttype name body ?ctype?

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 — which is also the C type of the result variable — is ctype. And if you don't specify it, ctype defaults to name. 🪄

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

So here's what body is responsible for: converting the function's result into a Tcl result and a Tcl status. The first has to be set into the interpreter we're 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 it 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 it isn't, an error is thrown. No shortcuts around that. 😌

::critcl::has-argtype name

Tests whether the named argument-type is known or not. Returns a boolean value — true if the type is known, false otherwise. Same energy as its result-type sibling. 🌸

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

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 holding the conversion result, and ctypefun is the type of the function argument itself. Both types default to name if they're the empty string or just not provided. Easy. ✨

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 gets stored in a helper variable in the underlying function.

body is called inside its own code block so local variables stay isolated, 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 declares name as an alias of argument type origname, which has to be defined already. If it's not — error. Thrown. Done. 🫠

::critcl::argtypesupport name code ?guard?

Defines a C code fragment for the already defined argument type name, and that fragment gets inserted before all functions using that type. Its whole purpose? Defining any supporting C types the argument type needs. 🔧

Now, if the type is used by many functions, the system makes sure only the first of the multiple insertions of the code fragment is active and the others get disabled. Efficient. The guard identifier is normally derived from name, but you can also set it explicitly via guard. That last bit lets different custom types share a common support structure without having to do their own guarding. Teamwork, honestly. 🤝

::critcl::argtyperelease name code

Defines a C code fragment for the already defined argument type name, and this one gets 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. Like, no exceptions, bestie.

An example of this are the variadic types supporting the special, variadic args argument to critcl::cproc's. Those allocate a C array for the collected arguments, and that array has to be released when the worker returns. This command is where you define the C code that does exactly that. 🧹

---

🦋 CONCEPTS 🦋

🔥 MODES OF OPERATION/USE 🔥

CriTcl can be used in three different modes of operation. Yes, three. We're fancy:

1. Compile & Run, and
2. Generate Package
3. Generate TEA Package

Compile & Run was the original mode, and it's the default for critcl_pkg. It collects the C fragments from the Critcl script, builds them as needed, and caches the results to improve load times later. Speedy. ⚡

The second mode, Generate Package, was introduced to enable the creation of (prebuilt) deliverable packages that don't depend on a build system existing on the target machine — you know, things like a C compiler. It was originally done through the experimental Critbind tool, and is now handled by the CriTcl Application, also named critcl. Glow up. ✨

Generate TEA Package is newly introduced with Critcl version 3. 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 for 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 — because that's an expensive operation, mainly in terms of the time it takes. 😮‍💨

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. Lazy loading, but make it iconic.

This part of the system uses standard functionality built into the Tcl core, i.e. the auto_index variable to map from commands to the scripts providing them, and the unknown command which uses that information when the command is needed. 🧠

A limitation of this behaviour: it is not possible to just use info commands to check for the existence of a critcl defined command. You also have to search in the auto_index array, in case it has not been built yet. Don't get caught out, bestie. 😭

okay so like — this whole "lazy until you literally have to" thing? You can absolutely override it with the control command critcl::load. The second you invoke it, the building gets forced, loading of the result included, no skipping, no deferring, we're doing this now 💅. But heads up bestie: once you've called that on a .critcl file, defining any more C code in that same file is not allowed any longer. Doors closed, keys thrown in the ocean. 🔒

---

🗺️ FILE MAPPING 🗺️

Every single .critcl file is backed by one private .c file containing that code, plus all the boilerplate it needs to get compiled and linked as a single shared library. One file, one library, clean.

The Embedded C Code fragments show up in that file in the exact same order they were defined in the .critcl file — with exactly one exception. C code you hand over via critcl::cinit gets shoved to the end, after all the other fragments. Translation: every fragment can see the symbols defined by earlier fragments, and the critcl::cinit fragment can see all of them, no matter where you physically placed it in the .critcl file. Iconic behavior, honestly. 👑

Note: a limitation of the current system is the near impossibility of C level access between different critcl-based packages. The problem is not the necessity of writing and sharing the proper extern statements — it's that the management (export and import) of package-specific stubs-tables is not supported. Which means dependent parts have to be forcibly loaded before their user, with all that entails. Go peek at section Runtime Behaviour for the relevant critcl limitation, and remember that a lot of older platforms don't support the necessary resolution of symbols — which is, lowkey, the whole reason stubs got invented for Tcl in the first place. 😭

---

💾 RESULT CACHE 💾

Compiling C code is time-consuming, so critcl doesn't just defer it as much as possible (see Runtime Behaviour, we been knew), it also caches the results. Bestie is efficient. ✨

So here's the tea: the first time you use a .critcl file FOO.tcl, the resulting object file and shared library get saved into the cache. Every future use of that same file? Reused. Loaded directly, no compilation required — provided the contents of FOO.tcl didn't change. As long as nothing moved, we're chillin'.

The change detection runs on MD5 hashes. One single hash gets computed for each .critcl file, based on the hashes of all C code fragments and configuration options — i.e. everything that affects the resulting binary. Nothing sneaks past. 🕵️

So as long as the input file doesn't change as per the hash, a previously built shared library found in the cache gets reused, and the compile and link stages are completely bypassed. Skipped. Not even invited.

The commands for managing the cache live in section Result Cache Management. But ngl — they're only actually useful to tools built on top of the package, like the CriTcl Application. Package writers have no need of them, so don't stress about it. 🙈

Last note, and it's a good one: the default directory for the cache is chosen based on the chosen build target. Which means you can park that cache on a shared (network) filesystem without having to fear interference between machines of different architectures. Mutual respect between platforms. 🌈

---

🚚 PRELOADING FUNCTIONALITY 🚚

The audience for this section is developers who wanna understand — and possibly mess with — the internals of the critcl package and application. Package writers can skip this whole thing, no offense taken. 🫶

This explains how the preloading of external libraries is actually realized.

Whenever a package declares libraries for preloading, critcl will build a supporting shared library that provides a Tcl package named preload. This package isn't distributed separately — it ships as part of the package that requires the preload functionality. It exports a single Tcl command:

• ::preload library — 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, and so is the command ::critcl::runtime::loadlib, which generates the ifneeded script expected by Tcl's package management. That generated ifneeded script contains the invocations of ::preload.

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

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

---

⚙️ CONFIGURATION INTERNALS ⚙️

Same audience disclaimer, bestie: this section is for developers who wanna understand and possibly modify the internals of the critcl package and application. Package writers, you can skip. 💜

This explains the syntax of configuration files and the configuration keys critcl uses to configure its build backend — i.e. how this part of the system gets at the compiler, linker, etc.

Highly recommend: open the file containing the standard configurations (path/to/critcl/Config) in the editor of your choice while reading this section, and use it as an extended set of examples that goes way beyond the simple defaults shown here. Trust. 📖

First up: the keys, the meaning of their values, plus examples pulled from the standard configurations distributed with the package. And note — when you're writing a custom configuration, you do not have to specify all the keys listed below. Only the ones whose default values are wrong or insufficient for the platform in question. Minimal effort, maximum slay. 💅

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 preloaded. 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. And again — it is recommended to open the file containing the standard configurations (path/to/critcl/Config) in the editor of your choice while 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 that looks like platform variable value sets up a platform-specific configuration variable plus its value. The variable has to be the name of one of the configuration keys listed earlier in this section, and the platform string tells you which platform the setting is for. All settings sharing the same identification string form the configuration block for that platform. 💅
6. A line of the special form platform when expression marks the platform — and every setting 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 gets 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 gets chosen as the default configuration. A large example of this feature is the handling of OS X 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. 😭 iconic behaviour honestly

7. A line of the special form platform copy sourceplatform copies the configuration variables and values currently defined in the configuration block for sourceplatform over to that of platform — overwriting existing values and creating missing ones. Variables of platform not defined 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 ✨

okay so buckle up bestie, we're in the changelog zone now 💅

1. Attention: the overall version (of the whole bundle, bestie) moves up to 3.1.18.1, but the versions of the packages critcl and critcl::app stay exactly where they were. no glow-up for them, sorry 🫶
2. Bugfix — generally removed a whole bunch of 8.5-isms that had snuck their way into 3.1.18 like uninvited party guests, which was breaking the ability to use it with Tcl 8.4. rude of them fr fr 😭
3. Bugfix — corrected a broken build.tcl uninstall. it was giving broken, now it's giving fixed 💀
4. Bugfix — package critcl::class got bumped to version 1.1.1. fixed partial template substitution that was breaking compilation of the generated code. she's compiling again, periodt ✨

---

🌸 CHANGES FOR VERSION 3.1.18 🌸

1. Feature (developer support, iykyk). merged pull request #96 from sebres/main-direct-invoke. this enables direct invokation of the "main.tcl" file for starkits from within a dev checkout — i.e. outside of a starkit, or starpack. living your best uncontained life 🦋
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. channels ate, no cap 🔥
3. Bugfix — issue #96. reworked the documentation around the argument type Tcl_Interp* to make its special status way more visible, explain its uses, and call it out from result types where its use will be necessary or at least useful. main character type, honestly 👑
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. choose your own adventure, bestie 💅
5. Bugfix — merged pull request #99 from pooryorick/master. fixes to the target directory calculations done by the install code. math was mathing incorrectly, now it maths correctly 🌈
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. collaborative slay 🫶
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. tests said "let me prove it" and then proved it 💖
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. type-correct and unbothered ✨
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 the STREP... macros into their proper place (the alloc section, not assert). she finally lives in the right section, iconic 🎀
10. merged pull request #83 from apnadkarni/vc-fixes. removed deprecated -Gs for MSVC builds, and other Windows fixups. Windows got a little makeover 💅
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. glow-up complete ✨
12. merged pull request #82 from gahr/home-symlink. modified tests to handle the possibility of $HOME being a symlink. flexible queen 🦋
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. almost everyone's invited to the function 😭
14. merged pull request #85 from snoe925/issue-84 to fix issue #84 breaking installation on OSX. OSX, you're back bb 🍓
15. merged pull request #87 from apnadkarni/tea-fixes to fix issue #86, the broken -tea option, which was generating an incomplete package. incomplete package? not on our watch 🙈
16. Feature — new package critcl::callback providing C-level functions and data structures to manage callbacks from C to Tcl. callbacks are calling back, bestie 🔥
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. list-ify everything, periodt 💜
18. Feature — package critcl::enum bumped to version 1.1. added basic mode handling, supporting tcl (the default) and +list (an extension enabling the conversion of multiple enum values into a list of their strings). enum said "I contain multitudes" 🌸
19. Feature — package critcl::emap bumped to version 1.2. extended the existing mode handling with the +list extension enabling the conversion of multiple emap values into a list of their strings. consistency is so slay ✨
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.

bestie do NOT get carried away imagining infinite range magic here — the vibes are bigger than the reality. check the package reference for the real details 🫶

---

🦋 CHANGES FOR VERSION 3.1.17 🦋

1. Extension: allow duplicate arg- and result-type definitions if they are fully identical. twins are fine as long as they're actually identical, no cap 👯
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. nobody gets lost in the assembled package anymore 😭💖
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). decluttered and correct, we love to see it 🎀
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. the patience?? legendary, crown him 👑
5. Bugfix: fixed issue #75. extended critcl::include to now take multiple paths. more paths, more power 🦋
6. added new compatibility package lmap84. a little nostalgia never hurt anybody ✨
7. fixed typos in various documentation files. the typos have been evicted 💅
8. fixed a 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. one more level up, bestie, keep climbing 🌈
9. new supporting package critcl::cutil. provides common C level facilities useful to packages (assertions, tracing, memory allocation shorthands). the little helper that could 🫶
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. everything's traceable now, the receipts are REAL 🧾
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. names got cuter and more useful 💜
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. mode mix-and-match, we stan 🌸
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. twins again, and they're both valid 💖

---

💜 CHANGES FOR VERSION 3.1.16 💜

1. New feature. extended critcl::cproc's argument handling to allow arbitrary mixing of required and optional arguments. chaos, but make it intentional 🔥
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.

bestie heads up — this one is flagged as a potential incompatibility, so if your code was relying on the old behaviour of an args argument that is last, go check it. seriously, go check it 🙈

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. ask and you shall receive 👑
4. added new result type Tcl_Obj*0, with alias object0. the difference to Tcl_Obj* is in the reference counting. same vibe, different refcount bookkeeping, iykyk ✨
5. extended the command critcl::argtypesupport with new optional argument through which to explicitly specify the identifier for guarding against multiple definitions. guard rails, but make them optional 🦋
6. Bugfix: fixed a 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. the log file must exist, no exceptions, periodt 💅
7. Bugfix: fixed a problem with the internal change to the hook HandleDeclAfterBuild. corrected the forgotten critcl::cconst. you had ONE job and now you've done it, congrats 🎀
8. Debugging aid: added comment holding the name of the result type when emitting result conversions. future-you says thank you 💖
9. Bugfix: fixed issue #60. unbundled the package directories containing multiple packages. all directories under "lib/" now contain exactly one package. one package per directory, clean and unbothered 🌸
10. Bugfix: fixed issue #62, a few dict exists commands operating on a fixed string instead of a variable. variables, bestie, they're right there 😭
11. Bugfix: fixed issue #56. release builders are reminded to run the tests. 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. FreeBSD said "identify me properly" and we did 💅
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. self-bootstrapping queen, no chicken/egg drama here 🐣✨

---

⭐ CHANGES FOR VERSION 3.1.15 ⭐

1. fixed version number bogosity with 3.1.14. the numbers were lying, now they're not, slay 💅

✨ CHANGES FOR VERSION 3.1.14 ✨

1. Fixed issue #36. Added a message to target all of the Makefile generated for TEA mode. Also tweaked other bits of the output so it's lowkey less noisy. 💅
2. Accepted the request implied in issue #54. We now unconditionally save the compiler/linker build log into the key log of the dictionary that cresults hands back, and save a copy of just the execution output in the brand-new key exl (aka the "execution log"). 🎀
3. Fixed issue #53. Made the docs for the commands critcl::load and critcl::failed way clearer about their results and about the throwing of errors (spoiler: it does not happen). 🙈
4. Fixed issue #48. Mode "compile & run" got a glow-up: it now allows new declarations in a file after it was built, instead of just erroring out. The new decls get built when they're needed. Mode "precompile" is unchanged and will keep trapping that situation, no cap. 💀
5. Fixed issue #52. Updated the local Tcl/Tk headers to 8.4.20, 8.5.13, and 8.6.4. fresh fresh fresh 🧚
6. Fixed issue #45. New feature command critcl::cconst. iconic behavior fr fr 👑
7. critcl::util: new command locate to find a file across a set of paths, and report an error when it's 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 figure out the location of the troubling declaration. 🕵️

---

🌸 CHANGES FOR VERSION 3.1.13 🌸

1. Merged PR #43. Fixed a bug loading adjunct Tcl sources. 🐛
2. Fixes in the documentation and generated code of package "critcl::enum". Bumped to version 1.0.1.
3. Fixes in the documentation of package "critcl::bitmap".
4. New package "critcl::emap". In essence a variant/cross of "critcl::bitmap" with behaviour like "critcl::enum". it's giving fusion cuisine 🍓
5. Merged PR #49. Fixed a documentation typo.
6. Merged PR #46. Fixed a documentation typo. (yes bestie, two typo PRs, we love a tidy docs era)
7. Merged PR #47. Fixes to test results so they match all the accumulated code changes. Also made them portable across Tcl versions (the error syntax varies, ugh). 🌈
8. New predefined argument- and result-type "wideint" mapping to Tcl_WideInt. 👑
9. New predefined argument-type "bytes" mapping to a 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 the C function underneath "critcl::cproc" with respect to how optional arguments are handled. 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 that cares about knowing whether the argument is default or not can now 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 the 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 from code generated with them before the final value of this setting was known. 🧚
13. Fixed an issue with the 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 because 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 of these are things that 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 an 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 the code version numbering forgotten with 3.1.9. (we literally forgot, oops) 😭
2. Fixed issue #35. In package mode (-pkg) the object cache directory is unique to the process, so 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-hashing with md5 to ensure unique file names in its per-user object cache.

3. Fixed an issue where the ccommand forgot to use its body as input for the UUID generation. Thus it ignored changes to it in mode compile & run, and did not rebuild 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 always be consistent with the headers, even when critcl's own copy of them is replaced by system headers. 👑
5. Fixed issue #31. Accepted a 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. (yes, the sneaky .<something> files) 🙈

---

🦋 CHANGES FOR VERSION 3.1.8 🦋

1. Fixed an issue with package indices generated for Tcl 8.4. Join the list of commands with a semi-colon, not a 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 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 so it works 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, bestie:
2. Added a brand new argument type "pstring" — that's short for "Pascal String" 💅 — a counted string, aka the glow-up combo of a string pointer plus a string length. Two things holding hands, slay.
3. Added new methods critcl::argtypesupport and ::critcl::argsupport so you can define and use extra supporting code for an argument type — which is literally what "pstring" up there is doing, using them to define the structure it needs. Iconic teamwork fr fr 🫶
4. Semi-bugfixes in the packages critcl::class and critcl::iassoc. Pragmas for the AS meta data scanner, making sure the template files actually get 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 so it can handle optional arguments — in a limited way, okay, not a full free-for-all 😌. And this is automatically available to critcl::class cproc-based methods too. The girlies stay winning 👑
3. Bugfix in the lassign emulation for Tcl 8.4. Unused variables now get properly set to the empty string. Bumped the version of the 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 (that's critcl::class cproc-based methods, iykyk). Now using NULL if there are no arguments, and taking the offset into account. No more wrong numbers being screamed at you 💀
3. Fixed how critcl::class handles package names. Honestly? Forgot that they may contain namespace separators 🙈. Bumped to version 1.0.1.
4. Extended a critcl::class generated error message in instance creation, purely for clarity's sake. Bumped to version 1.0.2.

---

💜 CHANGES FOR VERSION 3.1 💜

1. Added a new higher-level package: critcl::iassoc.

This package makes it so much easier to create code that associates data with an interpreter via Tcl's Tcl_(Get|Set)AssocData() APIs. You get to focus on your data, while all the necessary boilerplate C code needed to support it is generated by the package. Main character energy: the package does the chores, you do the vibes ✨

This package uses several of the new features that were added to the core critcl package — see below, bestie 👇

2. Added the higher-level package critcl::class.

This package simplifies the creation of C level objects with class and instance commands. You can write a class definition with class- and instance-variables and -methods, similar to a TclOO class, and all the necessary boilerplate C code to support it gets generated by the package. Periodt.

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. The main use currently envisioned is retrieval of the current package's name by utility commands, for use in constructed names. And good news: this particular information is always available, thanks 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 lets higher-level code generators generate the same type of C identifiers as critcl itself does. Same drip, different generator 💅

The new package critcl::class (see above) is a user of this command.

5. Extended the API with a command, critcl::source, which executes critcl commands found in a separate file in the context of the current file. This makes managing larger bodies of code way easier, because you can split them up into smaller, easier-to-digest chunks without triggering the generation of multiple packages. Snack-sized code, no bloat 🍓
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 inside higher-level code generators.

See the section Advanced: Diversions for the details of the provided commands.

The new package critcl::class (see above) is a user of these facilities.

7. Extended the API with commands that help developers generate proper C #line directives. This lets higher-level code generators generate and insert their own directives, ensuring that compile errors in their code are properly attributed — no blaming the wrong file, we don't do that here 😤

See the section Advanced: Location management for the 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 you the ability to define custom argument and result types for ::critcl::cproc. You're not stuck with the defaults, bestie 🌈

See the section Advanced: Extending cproc for the 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, which straight up violates the contract — the table is required to have a fixed address. This was a memory smash waiting to happen 💀 Thanks to Brian Griffin for alerting us to the general problem.

Not me emphasizing this one: non-static string table + Tcl_GetIndexFromObj = bad news. Keep it static, periodt.

---

⭐ 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). The era of gaslighting yourself into thinking the build worked is over 🙈
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. Consistency slay ✨
3. Documentation cleanup, mainly in the installation guide, and the README.md shown by github.

---

🌈 CHANGES FOR VERSION 3.0.5 🌈

1. Fixed a 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. Docs got a whole wardrobe upgrade 🎀

---

🧚 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 (the libinclude configuration setting).
3. Extended critcl to handle the -l:path format of -l options. GNU ld 2.22+ handles this by searching for the path as is. That's good when you're specifying static libraries, because a plain -l looks for shared libraries in preference over static ones. critcl handles it now, since older GNU ld's do not understand it, and neither do 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. Also simplified the handling of bufferoverflowU.lib, making use of the same mechanism and collapsing the two configuration sections we had back into one. Two became one, the merge ate 💅
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 to 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, fr fr.
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 an 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. Ty bestie 🫶
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 — this unbreaks generated meta data and the generated package load command. The way that these two belong together, no cap 💜
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. Yeah you actually need a C compiler for this, sorry babes 😭
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: environments 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 got deprecated back in version 2.1, with critcl::targetplatform stepping in as its replacement — but it was left hanging around for compatibility reasons. Now? Gone. Removed. 💀
2. The command critcl::compiled was kept in version 2.1 for compatibility, but with semantics that straight-up contradicted its own name. That contradiction has been removed, which changes the visible semantics of the command so it finally matches what it's called. ✨
3. The jump to version 3 had to happen because of those two incompatible visible changes above, fr fr.
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".

Heads up bestie: 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

---

and that's a wrap on the whole critcl(3tcl) page bestie!! 🎉 source doc, version 3.1.18, dated like the lil footer always says — 3.1.18, critcl(3tcl), periodt. 💅