critcl::app(n) 2.1 doc "C Runtime In Tcl (CriTcl)"

Name

critcl::app - CriTcl Application Package Reference

Table Of Contents
Synopsis
Description
API
Options
Modes Of Operation/Use
Package Structure
Changes for version 2.1
Changes for version 3
Authors
Bugs, Ideas, Feedback
Keywords
Category
Copyright

Synopsis

package require Tcl 8.4
package require critcl::app ?2.1?
package require critcl ?2?
package require platform ?1.0.2?
package require cmdline

::critcl::app::main commandline

Welcome to the C Runtime In Tcl, CriTcl for short, a system to build C extension packages for Tcl on the fly, from C code embedded within Tcl scripts, for all who wish to make their code go faster.

This document is the reference manpage for the critcl::app package. Its intended audience are developers working on critcl's internals. Writers of packages with embedded C code can ignore this document. If you are in need of an overview of the whole system instead, please go and read the Introduction To CriTcl.

This package resides in the Application Layer of CriTcl.

arch_application

, implementing the functionality of the CriTcl Application, and through this, the mode generate package. The actual application is (only) a shim wrapping around this package. It itself is build on top of the core package critcl.

API

The package exports a single command

::critcl::app::main commandline: The commandline is a list of options and input files, in this order, with both parts possibly empty. The exact set of options supported, their meaning, and interaction is detailed in section Options below. For a larger set of examples please see section "Building Critcl Packages" in the document about Using CriTcl.

Options

The following options are understood

-I path

This option specifies an additional global include path to use during compilation of ".critcl" files. All values are used if this is specified multiple times.

This option is irrelevant when generating a TEA package (see option -tea below).

-cache path

This option specifies the path to the directory to use as the result cache. If not specified it defaults to "~/.critcl/<platform>", or, when generating a package (see option -pkg below), to "~/.critcl/<pid>.<epoch>", When specified multiple times the last value is used.

This option is irrelevant when generating a TEA package (see option -tea below).

-clean

When specified the result cache is emptied, i.e. all files and directories found inside are deleted) before compilation begins.

This option is irrelevant when generating a package (see option -pkg below) because this mode starts out with a unique and empty result cache.

This option is irrelevant when generating a TEA package (see option -tea below).

-config path

This option specifies the path to a custom configuration file, allowing the user to use their own target specifications. If not specified a hardwired default configuration embedded in the system core is used instead. When specified multiple times the last value is used.

This option is irrelevant when generating a TEA package (see option -tea below).

-debug mode

This option activates compilation with debugging. It accepts the modes below. When specified multiple times the combination of all modes is used.

This option is irrelevant when generating a TEA package (see option -tea below).

memory: This mode activates memory debugging of allocations made through the Tcl core.
symbols: This mode activates building of all ".c" files with debugging symbols.
all: This mode activates both memory and symbols.

-disable name

This option sets the value of the custom build configuration option name to false. It is equivalent to "-with-name 0".

The information is validated only if one of the ".critcl" input files actually defines and uses a custom build configuration option with that name.

This option is irrelevant when generating a TEA package (see option -tea below).

-enable name

This option sets the value of the custom build configuration option name to true. It is equivalent to "-with-name 1".

The information is validated only if one of the ".critcl" input files actually defines and uses a custom build configuration option with that name.

This option is irrelevant when generating a TEA package (see option -tea below).

-force

When specified compilation is always done, even if a shared library for the file exists already. This effect can be had through cleaning the cache (see above) as well, except that it is lazy in the destruction of files and will not destroy files unrelated to the ones we are building.

This option is irrelevant when generating a package (see option -pkg below) because this mode starts out with a unique and empty result cache.

This option is irrelevant when generating a TEA package (see option -tea below).

-help

This option will cause the system to print a short help about command line syntax and options and then exit the application.

-keep

This option will cause the system to keep the ".c" files generated by a run in the result cache. When generating a package (see option -pkg below) this also prevents the deletion of the unique result cache used by the run. This option is intended for the debugging of critcl itself, where it may be necessary to inspect the generated C code.

This option is irrelevant when generating a TEA package (see option -tea below).

-libdir path

This option specifies the path under which the packages generated via option -pkg are saved. When specified multiple times the last value is used. When not specified at all the default, "lib", is used. Note how this is a relative path, placing the result into the current working directory.

-includedir path

This option specifies the path under which any generated package headers are saved. It also specifies a path to search include files in, like for -I. When specified multiple times the last value is used as destination, however all previous values are kept on the include search path. When not specified at all the default, "include", is used. Note how this is a relative path, placing the result into the current working directory.

This option is irrelevant when generating a TEA package (see option -tea below).

-pkg

The default mode of the application is to build the ".critcl" files listed on the command line and save the results in the result cache. Essentially pre-filling the cache with important packages, cutting down on the time needed to use these packages.

This option activates one of the other modes, package generation. In this mode the input files are processed first as usual, however after that they are bundled into a single library and additional files are generated to make this library usable as a regular Tcl package.

The option -tea, see below, invokes the last mode, TEA generation. If both options, i.e. -pkg and -tea are specified the last one specified wins.

In this mode the options -clean and -force are irrelevant and ignored. In contrast, the option -libdir is relevant in both this and -tea mode.

When this option is specified the basename of the first file argument after the options is used as the name of the package to generate. If the extension of that file indicates a shared library (".so", ".sl", ".dylib", and ".dll") it is also removed from the set of input files. A ".tcl" file is kept as part of the input. A single file without extension is assumed to actually have a ".tcl" extension. A file without extension, but other input files following is treated like the name of a shared library proper, and removed from the set of input files.

Examples:

	... -pkg ... foo
	=> Package name is: foo
	=> Input file is:   foo.tcl

	... -pkg ... foo bar.tcl
	=> Package name is: foo
	=> Input file is:   bar.tcl

	... -pkg ... foo.tcl
	=> Package name is: foo
	=> Input file is:   foo.tcl

	... -pkg ... foo.so bar.tcl
	=> Package name is: foo
	=> Input file is:   bar.tcl

-show

This option, when specified, will cause the system to print the configuration of the chosen target to stdout and then exit. The choice of target can be influenced through the option -target (see below).

-showall

This option, when specified, will cause the system to print the whole chosen configuration file to stdout and then exit. The choice of configuration file can be influenced through the option -config (see above).

-target name

This option overrides the default choice of build target with the user's choice. When specified multiple times the last value is used. The named target must exist in the chosen configuration file. Use option -targets (see below) to get a list of the acceptable targets. The choice of configuration file can be influenced through the option -config (see above).

This option is irrelevant when generating a TEA package (see option -tea below).

-targets

This option, when specified, will cause the system to print the list of all known targets from the chosen configuration file to stdout and then exit. The choice of configuration file can be influenced through the option -config (see above).

-tea

Similar to option -pkg, except that the invoked mode does not generate binaries, but a directory hierarchy containing the ".critcl" file, its companion files, and a TEA-lookalike build system with most of the needed support code (incliding copies of the critcl packages).

If both options, i.e. -pkg and -tea are specified the last one specified wins.

In this mode the options -clean, -force, -cache, -includedir, -enable, -disable, and -with-FOO are irrelevant and ignored. In contrast, the option -libdir is relevant in both this and -pkg mode.

Examples:

	... -tea ... foo
	=> Package name is: foo
	=> Input file is:   foo.tcl

	... -tea ... foo bar.tcl
	=> Package name is: foo
	=> Input file is:   bar.tcl

	... -tea ... foo.tcl
	=> Package name is: foo
	=> Input file is:   foo.tcl

	... -tea ... foo.so bar.tcl
	=> Package name is: foo
	=> Input file is:   bar.tcl

-with-name value

This option sets the value of the custom build configuration option name to value.

The information is validated only if one of the ".critcl" input files actually defines and uses a custom build configuration option with that name.

This option is irrelevant when generating a TEA package (see option -tea above).

Modes Of Operation/Use

CriTcl can be used in three different modes of operation, called

Compile & Run, and
Generate Package
Generate TEA Package

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

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

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

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

Package Structure

Packages generated by critcl have the following basic structure:

<TOP>
+- pkgIndex.tcl
+- critcl-rt.tcl
+- license.terms (optional)
|
+- tcl (optional)
|  +- <tsources files>
|
+- <platform>
   +- <shared library>

Notes

The file "pkgIndex.tcl" is the standard package index file expected by Tcl's package management. It is sourced during a search for packages, and declares the package to Tcl with its files, and how to handle them.
The file "critcl-rt.tcl" is a helper file containing the common code used by "pkgIndex.tcl" to perform its tasks.
The file "license.terms" is optional and appears only if the ".critcl" file the package is generated from used the command critcl::license to declare package author and license.
All files declared with the command critcl::tsources are put into the sub-directory "tcl".
The shared library generated by critcl is put into a platform-specific sub-directory.

The whole structure, and especially the last point, enable us to later merge the results (for the same package, and version) for multiple target platforms into a single directory structure without conflict, by simply copying the top directories over each other. The only files which can conflict are in the <TOP> and "tcl" directories, and for these we know that they are identical across targets. The result of such a merge would look like:

<TOP>
+- pkgIndex.tcl
+- critcl-rt.tcl
+- license.terms (optional)
|
+- tcl (optional)
|  +- <tsources files>
|
+- <platform1>
|  +- <shared library1>
+- <platform2>
|  +- <shared library2>
...
+- <platformN>
   +- <shared libraryN>

Changes for version 2.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.
Fixed internals, preventing information collected for multiple ".critcl" files to leak between them. Notably, critcl::tk is not a global configuration option anymore.
Fixed the command critcl::license to be a null-operation in mode "compile & run", instead of throwing an error.
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.
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.
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.
Fixed bug in critcl::debug which prevented recognition of mode "all" when it was not the first argument to the command.
Fixed bug in "preload.c" preventing its compilation on non-windows platforms.
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.
Extended/reworked critcl::tsources to be the canonical way of declaring ".tcl" companion files even for mode "compile & run".
Extended/reworked critcl::tsources to allow the use of a ".critcl" file as its own Tcl companion file.
Extended critcl::framework to internally check for OS X build target, and to ignore the declaration if its not.
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.
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.
Extended the code handling the search for preloaded libraries to print the paths it searched, making debugging of a search failure easier.
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.
A new command critcl::load forces the build and load of a ".critcl" file. This is the official way for overriding critcl's default lazy-build-&-load-on-demand scheme for mode "compile & run".

Note that after using critcl::load / critcl::failed in a ".critcl" file it is not possible to use critcl commands in that file anymore. Doing so will throw an error.
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.
Extended critcl::check with logging to help with debugging build-time checks of the environment, plus an additional optional argument to provide labeling.
Added a new command critcl::checklink which not only tries to check the environment via compiling the code, but also its linkability.
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.
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.
Extended the critclk 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.
Dropped the unused commands critcl::optimize and critcl::include.
Dropped -lib mode from the critcl application.
Dropped remnants of support for Tcl 8.3 and before.

Changes for version 3

The command critcl::platform was deprecated in version 2.1, superceded by critcl::targetplatform, yet kept for compatibility. Now it has been removed.
The command critcl::compiled was kept with in version 2.1 with semantics in contradiction to its, for compatibility. This contradiction has been removed, changing the visible semantics of the command to be in line with its name.
The change to version 3 became necessary because of the two incompatible visible changes above.
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.
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:
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.
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.
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.
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.

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 such at https://chiselapp.com/user/andreas_kupries/repository/CriTcl/reportlist. Please also report any ideas for enhancements you may have for either package and/or documentation.

Note that this is not critcl's official bug tracker, but the repository where inofficial and experimental development of critcl is taking place. It is the best which can be done because an official bug tracker does not exist.

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