KitCreator

Difference between version 39 and 41 - Previous - Next
'''[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.  


<<categories>> TclKit