C-KERMIT 10.0 DEVELOPMENT

TABLE OF DEVELOPMENT BUILDS

CKUBUILDLOG SCRIPT

Before C-Kermit 10.0 can be released, it's necessary to make sure it builds on every possible platform, old and new. The builds are tracked in the tables on THIS PAGE. As of 6 June 2023, to alleviate the tedium of putting together the data for each build a new Kermit script, ckubuildlog, is available for (so far) Unix-based platforms only.

With ckubuildlog you don't have to transcribe or copy/paste all the data; the script creates a plain-text HTML table row that you can email me so I can plug it into the big builds table.

Starting with C-Kermit 10.0 Beta.10 development builds as of 23 June 2023, this script is / is included with the C-Kermit source-code files so it will go in the C-Kermit source-code directory automatically and can be invoked after compilation simply by "./ckubuildlog"; no installation required.

Note that 'wermit' is the name given to the freshly-built C-Kermit executable, so that it doesn't clash with any earlier version called 'kermit' or 'ckermit'. The idea is that you check the wermit binary to make sure it works to your satisfaction before superseding any previously installed version.

Thanks to Peter Eichhorn for testing and correcting ckubuildlog on HP-UX.

Update: new simplified installation and usage — 2023-06-23

You don't have to install ckubuildlog the way you install other Kermit scripts: you don't have to put it in some directory in your PATH or change the the top ("shebang") line to make it point to a kermit executable. Instead, it is executed by the 'wermit' program you just built; let's say you're already cd'd to that directory. In this example the tar archive is called x.tar.gz (a gzip'd [compressed] tar archive of the C-Kermit files):

rm -f x.tar.gz	IMPORTANT: Remove any previous x.tar.gz files *
wget https://kermitproject.org/ftp/kermit/pretest/x.tar.gz **
gunzip x.tar.gz	Uncompress the tar archive ***
tar xvf x.tar	Unpack the tar archive (about 30 source files plus ckubuildlog) ***
ls -l ckubuildlog	Check that it has execute permission ('x') (it should)
chmod +x ckubuildlog	Do this only if it lacks execute permission

*	If an x.tar.gz file already exists in the directory, wget stores the incoming (newer) file with a different name (e.g. x.tar.gz.1) instead of renaming the existing file, which can be VERY CONFUSING.
**	wget is the one-step downloader, available for both Unix and VMS. FTP can also be used but several steps are required, and it doesn't work with symlinks like x.tar.gz.
***	In recent tar versions, steps 3 and 4 can be combined: "gunzip x.tar.gz" automatically gunzips the archive before extracting the files. You can also use "tar zxvf x.tar.z" if your tar program has that option.

Here's what you do to build C-Kermit and generate the build report on a Linux system:

make clean	Remove leftover ckxxxx.o (object files) so all modules will be compiled
make linux 2> log	Build C-Kermit and direct warning/error messages to a file named 'log'
./ckubuildlog	Run ckubuildlog to generate the build report

The report is a file named xxxx.txt, where xxxx is the makefile target name, "linux" in this example; it could also be freebsd, netbsd, macos, or any of the many other C-Kermit makefile targets. Please email the report file to me at fdc@columbia.edu.

You can do additional builds for the same platform in the same directory, e.g. "make linux-ssl", "make linux-krb5", "make linux-clang"

If you omit ">2 log" from the make command, the result file won't include any warnings or errors and I won't know what might need fixing.

Sample report

To generate the build report after building C-Kermit, simply run ckubuildlog, which is executed by the C-Kermit binary you just built:

./ckubuildlog

Here are the results for NetBSD 9.3 (the left column is produced by ckubuildlog):

Entry	Meaning
<tr>	New table row
<td>NetBSD 9.3	OS name and version
<td>amd64	Hardware architecture
<td>make netbsd	Build command
<td>2023-05-09	Date of source code yyyy-mm-dd
<td>2491536	Size of wermit executable in bytes
<td>gcc 7.5.0	Compiler name and version
<td>	Optional security features included (SSL, Kerberos)
<td>OK	Build status; OK or Failed
<td>	Build warnings and/or errors (in this case, none)

If the build failed, ckubuildlog should detect it and produce an appropriate result.

The <tr> and <td> are HTML table row and column notation, so I can just plug the report into the C-Kermit 10.0 builds table. If there were any warnings or errors, they would be shown in the final <td>. You can email this result to me as an attachment and I'll add it to the builds table and see what I can do about any warnings or errors.

If some of the information — e.g. OS name/version or compiler name/version — is missing or wrong, let me know and I'll see if I can fix ckubuildlog to know about your platform.

Shell script

If you do C-Kermit builds often, you can further simplify the process by putting the commands into a shell script. Here's an example for building the most recent upload to the C-Kermit pre-Beta area (periodic uploads between Beta tests to the URL shown (note: x.tar[.gz] and x.zip are always links to the most recent upload):

#!/bin/sh
if [ $# -eq 0 ]; then echo Usage: $0 makefile-target; exit 1; fi
rm -f x.tar.gz*
wget https://kermitproject.org/ftp/kermit/pretest/x.tar.gz || exit 1
gunzip x.tar.gz || exit 1
tar xvf x.tar || exit 1
chmod +x ckubuildlog || exit 1
make clean || exit 1
make $1 2> log
./ckubuildlog
exit 0

The part part beginning with "make clean" could be separated out into a separate script if you're going to do multiple builds (because you don't need to download the same tarball again and again). See below for more about multiple builds.

For a real Beta test (the latest one), the URL would be:

https://www.kermitproject.org/ftp/kermit/test/tar/x.tar.gz

Multiple builds

If you do multiple builds in the same directory using different makefile targets, each build result will have a distinct name, e.g. "linux.txt", "linux-clang.txt" "linux+ssl.txt", "linux+krb5.txt", etc. You can send them as separate email attachments, but it would be better (easier) at both ends if you combined them all into one file, e.g. (for Linux):

cat linux*.txt > linux-combined.txt

Then send me the linux-combined.txt file (or netbsd-combined.txt, whatever you were building variations of) and I can simply copy and paste this single attachment into the build table. Otherwise — since I'm required to use Gmail — the process is ridiculously labor-intensive and aggravating.

Obviously (or perhaps not so obvious) if you build a minimal version of C-Kermit without features needed by ckubuildlog (e.g. make linux KFLAGS=-DNOSPL 2> log), ckubuildlog won't work! (NOSPL = "No script programming language".)

Options

ckubuildlog accepts the following command-line options:

-v	Verbose - print progress messages.
-h	Help - prints a help message and exits.
"osname version"	OS name and version in doublequotes
"resultfile=name.txt"	Name for result file (overrides default name)
"logfile=name"	Name for errors/warning log file (overrides 'log')
"kflags=list"	KFLAGS used in the 'make' command

The NetBSD build shown in the previous section went smoothly. Most notably, the correct operating-system name and version are shown. The situation is more complicated with (say) Linux, where the normal APIs for getting this information return just "Linux" and the kernel version, rather than the specific Linux variation (distribution) such as Ubuntu, Fedora, Debian, etc, and its version. Simarly, Apple systems return the Darwin Kernel name and version rather than the familiar OS name and version, such as macOS or Mac OS X. Version 2 of ckubuildlog goes to considerable lengths to hunt down and report these for both Linux and Macs.

If ckubuildlog doesn't show you the right OS name and release, you can provide them yourself on the command line (in doublequotes, since the text almost certainly includes spaces); examples:

ckubuildlog "AlmaLinux 8"
ckubuildlog "Raspberry Pi 11"
ckubuildlog "Sparky 2022"
ckubuildlog "Springdale 8"
ckubuildlog "Voyager 22.10"
ckubuildlog "Zorin 16.2"
ckubuildlog "GhostBSD 22.01"
ckubuildlog "LibertyBSD 6.1"
ckubuildlog "MidnightBSD 2.2.0"

Fine points...

Custom C-Kermit builds

Feature-reduced C-Kermit builds with KFLAGS like -DNOICP, -DNOSPL, -DNOTCP, etc, won't be able to run ckubuildlog (obviously in some cases, not so obvious in others). It does no good to execute ckubuildlog from some other C-Kermit binary because then it will not be reporting on the binary you just built.

Including extra 'make' parameters

If you build C-Kermit with extra 'make' parameters, e.g.

make linux "KFLAGS=-DNODIAL -DNOUUCP"

the extra material is not seen by C-Kermit itself, and therefore not by ckubuildlog. In that case you can supply them in the ckubuildlog command line, e.g.:

./ckubuildlog linux kflags="-DNODIAL -DNOUUCP"

Multiple resultfiles with different KFLAGS

As a consequence of the previous item, if you are doing a series of builds with the same target but different KFLAGS, the result file for each build would write over the previous one. In this situation you can specify a different result filename for each one on the command line, e.g.:

./ckubuildlog openbsd kflags="-DNODIAL -m64" resultfile="openbsd3.txt"

Fixing ckubuildlog to know about your OS

If you want ckubuildlog to report the OS name and version correctly itself, you can check the relevant C-Kermit variables; type or copy-paste the following line at the C-Kermit command prompt:

show variable osname osversion osrelease platform

to see which, if any, of these variables contain the correct information. If none of them do then check /etc/*release* and if that fails look around elsewhere. When/if you find where the osname and version are stored, let me know and I'll add your platform to the script.