 |  | |||
 | | | | |
top pageS
Soapbox
Blog Company
About
| genkit, continued Or: what to do if the genkit build of Tclkit does not work out of the box. The following notes are grouped by step number (1..6) as mentioned on the previous page. step 1 - fetch/unpack all packages This step fetches a number of files and places them in a "tars/" subdirectory. This is the first use of the genkit script, and also the first step where an external "tclsh" is used to run genkit. If your copy of tclsh is too old, it may fail - genkit has only been tested with 8.3, 8.4, and 8.5. After fetching, genkit unpacks the tars into a "src/" subdirectory. One refinement, is that before fetching & unpacking, genkit checks for the existence of a suitable subdirectory in "cvs/" - if found, a symlink to it is created in src/, and no fetching/unpacking takes place. This can be convenient to manage a large set of packages as CVS check-outs. At the end of this step, the "src/" directory must exist, with subdirectories called "tcl/", "tk/", "itcl/", "mk/", "thrive/", "vfs/", and "zlib/". If all else fails, you could try to set these up manually - but keep in mind that you still need a working tclsh to be able to run the next step. step 2 - build the tcl core itself This is a bootstrap step which creates the tclsh interpreter that will be used for all the remaining steps. It does little other than choosing the directory to build Tcl in, i.e. "build/tcl/<hostname>/", and to install it in: "install/tcl/<hostname>/". The hostname is obtained from the Unix "hostname" command. There are a number of directories which all use this same hostname-subdirectory structure. This makes it easy to use the same build across multiple platforms, for example by mounting the same area on all of them via NFS. The directories are:
The "out/" area is particularly useful for debugging build problems, since it contains the log files of all the actual package builds performed by genkit. For example, this first step will produce a file called "out/<hostname>/tcl" with a full transcript of the build of tclsh itself. Once step 2 is done, a working tclsh should be present in the "install/" area. step 3 - build all remaining packages Now that you have a freshly compiled tclsh, it will be used to build with and to link to. That is why all further steps call genkit as a shell script, and not via the tclsh needed above. The shell script will locate the tclsh binary built in step 2 and re-launch itself. A number of packages will be built. For this, genkit is really just a wrapper to set up the proper incatations of configure & make calls, adding all the necessary options. There is some logic at the start of the genkit script to set up a number of default options depending on the platform. The current list of setting is quite limited. There is however also a way to override these - if you create a file "genkit.local" with the options you'd like to change, then genkit will evaluate this script after having set its own defaults and before starting any of the requested builds. Genkit is able to re-build one of more packages. The "sh genkit B all" command is actually shorthand for: sh genkit B zlib vfs thrive mk itcl tk kitshlite \ Each of these packages are built, and as you can see some of them are actually built in both static and dynamic variants. Not all of these packages are absolutely crucial. For example, "tk" and "tkdyn" are obviously not needed if all you want is a tclkitsh, i.e. a non-gui runtime. Even if some of these fail to build, you may still be able to create a tclkit variant which is good enough for your purposes. The "mk" package is Metakit, and is written in C++. If a decent C++ compiler is not available, then Tclkit Lite might be an alternative. The main requirement is that at least one of the following builds succeeds: kit, kitlite, kitsh, or kitshlite. Some known failures will be listed here (this information is likely to change):
Some problems may require some serious debugging to fix. Since genkit is just a wrapper around each of the package's own build processes, you can always go in and repeat the builds manually until they produce an acceptable binary. For example, to debug problems in the Metakit package, you can do: cd build/<hostname>/mk To find out what went wrong in the first place, look in the output transcripts generated by genkit, e.g. "less out/<hostname>/mk". step 4 - collect build results into a tar file This step is optional, but greatly appreaciated. It produces a tar file containing all the build transcripts as well as all the relevant binaries needed to construct a new tclkit executable. The tar file has the name "result-<hostname>.tar.gz". If you send this to me, I have scripts to summarize the pprogress, such as this status report. Most importantly, I can re-generate new versions of all tclkit builds with this, if only one of the script files in VFS tail of the tclkit is modified, since this requires no re-compilation. Many many dozens of binaries have been constructed this way already, including most of those listed in the download matrix. step 5 - run a quick test that tclkit works One the "kit" executable file has been built, it can be used to run a quick sanity check that it works as expected. The quick test performed in step does not yet include the "itcldyn" and "tkdyn" shared libraries into the final result, but still loads them separately off the disk. Nevertheless, this step catches most buld problems, since all the necessary pieces are briefly exercised. Note that failure of step 5 does not mean that step 6 will fail as well. There have been cases where the somewhat naive test done in this step fails, even though the result produced by step 6 turns out to be a perfectly functional tclkit after all. step 6 - build the final tclkit executable The final post-link step takes all the pieces and combines them into a real tclkit runtime. The main task here is to insert the itcldyn and tkdyn shared libraries into the runtime VFS before appending it to the end of the kit executable. Failures at this stage are usually caused by problems in the startup/initialization phase, preventing the test version created in step 5 from applying these changes to VFS. step 7 - miscellaneous There is a lot more to be said about the whole process, such as how tclkit starts up, how it differs from a "standard" (unwrapped) Tcl system, and what else you can do to solve problems which genkit can not automatically deal with. Stay tuned... | tclkit index • Overview • Download • Links | |||
| | | | | |
| | |