'''[http://kitcreator.rkeene.org/%|%KitCreator]''', by [Roy Keene], is a simple system for building a [Tclkit]. It's purpose is to ease creation of [Tclkit%|%Tclkits] for various platforms. ** Builds ** [http://www.rkeene.org/devel/kitcreator/kitbuild/%|%released builds]: [http://kitcreator.rkeene.org/kitcreator%|%KitCreator Web Interface]: Choose desired kit via a form. ** Description ** It will work for cross-compiling Tclkits if you bootstrap a local Tclkit first. It is intended to resemble as closely as possible the authentic Tclkit. What sets this project apart from other similar projects is that: 1. It attempts to be modular; 1. It supports cross-compiling; 1. It downloads the source from their original repositories; 1. It allows you to specify an arbitrary version of Tcl (including CVS); and 1. It uses GNU Autoconf scripts for compiling the part of the Tclkit that brings the whole thing together (the Kitsh) **Discussion** [MiR] 2022-10-21 : Did anyone realize, that KitCreator Online buildsystem is broken since some months? Nightly build almost all fail and building manually doesn't work either, all seem to fail already when trying to build tcl-core. This applies to almost any version and any OS. I'm trying to get a working win32 8.5.xx (xx>=9) but no chance. Sigh! tma 2022-10-21: I just successfully created the following: Tcl 8.5.19, KitCreator 0.12.2, Platform win32, Without Tcl pkgs/ and all encodings, Metakit-based, Unthreaded, Packages: mk4tcl, tk URL: https://kitcreator.rkeene.org/kits/617deed463d6f77570c1242f0e1abee8047327e3/tclkit.exe [MiR] You're right, this is very strange indeed. When I find some time I'll do some testing, what builds fail and why... 8.7a5 at least seems to fail with kitsh/build.log:kitInit.o:kitInit.c:(.text+0x158): undefined reference to `Thread_Init'. Hm. ***Build for native macosx*** [jbr] : This just hacks the --enable-aqua switch into the Tk build.sh. It needs something better though. ======none Index: tk/build.sh ================================================================== --- tk/build.sh +++ tk/build.sh @@ -1,6 +1,8 @@ #! /usr/bin/env bash + +export CONFIGUREEXTRA=--enable-aqua if [ ! -f 'build.sh' ]; then echo 'ERROR: This script must be run from the directory it is in' >&2 exit 1 ====== ======none brew install openssl export KC_TLS_SSLDIR=/usr/local/opt/openssl export KITCREATOR_PKGS="tk thread tcllib critcl tls udp tclpkcs11 tdom" ./kitcreator --enable-threads --enable-64bit ====== ***tnc*** [AMG]: The following adds support for the [tnc] package included within [tDOM]. ======none tar -xf ~/tdom-0.9.1-src.tgz && mkdir tnc && mv tdom-0.9.1 tnc/buildsrc && sed -i '/^INSTALL_DATA\>/s/444$/644/' tnc/buildsrc/extensions/tnc/Makefile.in && sed -i '/-DUSE_TDOM_STUBS=1/d' tnc/buildsrc/extensions/tnc/configure && cat > tnc/build.sh << "EOF" && #! /usr/bin/env bash # BuildCompatible: KitCreator version=0.3.0 configure_extra=("--with-tdom=${pkgdir}/../tdom/inst/lib") function preconfigure() { cd extensions/tnc } EOF chmod +x tnc/build.sh ====== When running `kitcreator`, be sure to include `tdom tnc` in the value of `KITCREATOR_PKGS`. This is a partial solution, a quick fix. The above does not tie into KitCreator's machinery for downloading packages. As written, it assumes you have the tdom sources downloaded to `~/tdom-0.9.1-src.tgz`. It works for me because, due to firewall shenanigans at the office, I'm already having to run KitCreator with all packages pre-downloaded, bypassing its built-in download machinery. I feel a better solution would be to update the tdom build script to internally build a tnc package as well as tdom itself. ***zlib*** [AMG]: KitCreator targets an older version of zlib (1.2.8). The following upgrades to 1.2.11: ======none mkdir zlib/src && ln ~/zlib-1.2.11.tar.gz zlib/src && sed -i '/^version=.*/s//version=1.2.11/' zlib/build.sh ====== ***Unwanted console window*** [AMG]: When compiling for Windows, add `LDFLAGS=-mwindows` to the build command to hide the console window. ***No Xft support*** [AMG]: When I use KitCreator to cross-compile Tclkit, it ends up not supporting Xft. First off, the build system's `xft.pc` and other `pkg-config` files are being used, rather than the target system's `xft.pc`. I fixed this by setting these environment variables when running KitCreator: ======none PKG_CONFIG_PATH= PKG_CONFIG_LIBDIR=$SYSROOT/usr/lib/pkgconfig:$SYSROOT/usr/share/pkgconfig PKG_CONFIG_SYSROOT_DIR=$SYSROOT ====== Next, I'm getting `-L/usr/lib64` in my X library search path, even though that's outside my sysroot and the target system is 32-bit. This is coming from Tk's configure script's X11 detection code, which happily finds the host system's files. I don't have a fix for this yet, but manually running configure with the following options help: ======none --x-includes=$SYSROOT/usr/X11R6/include --x-libraries=$SYSROOT/usr/X11R6/lib ====== Finally, the real killer. `pkg-config --libs xft` yields `-L$SYSROOT/usr/X11R6/lib -lXft -lfreetype -lXrender -lfontconfig` (with `$SYSROOT` expanded). The listed libraries also depend on `libXext.so`, but the linker isn't given `-rpath-link`, so it doesn't know where to find that library. Only on SunOS is `-L` consulted when searching for libraries needed by those explicitly listed on the command line. The only way I was able to fix this last problem was by editing `xft.pc` to include `-lXext` in the `Libs:` line. [JRP] 2021-01-18: I also had trouble with Xft when building a Linux / AMD64 Tclkit. I downloaded the current KitCreator source to try to turn Xft on manually. You have to run build/pre.sh first, and I had to fix the line ====== KITSHROOTDIR="$(ls -1d kitsh/buildsrc/kitsh-*/)" ====== to read ====== KITSHROOTDIR="$(ls -1d ../kitsh/buildsrc/kitsh-*/)" ====== ...for the pre.sh script to run. Once I did that, `./kitcreator --enable-64-bit` created a Tclkit with tclvfs, zlib, tk, itcl, and mk4tcl. Looking at the build log for Tk shows ====== checking whether to use xft... yes checking for X11/Xft/Xft.h... yes ====== ...which is exactly what I want. I didn't have to change anything about how Tk is built. <> TclKit