1. --with-tclinclude no longer exists (not a problem, as the include path was correctly picked up)

That was intentional. When porting the build, the logic for that was, IMO, unnecessarily complicated for what seemed like an unnecessary use case. --with-tcl=/tcl/install/root will do the trick (and if it doesn't, it's an exotic tcl installation!).

1. the install-test bombs

Can you please show us the output that generates? If it's not showing anything, that's a bug - it's supposed to propagate whatever error was triggered.

1. no install rule for the man page.

There is not. It had not occurred to me that anyone would install a man page for a tcl extension. That's now on the list of TODOs.

Strange, I did not have to manually install the man page for version <= 3.49.2.

That was a different build system and it literally never crossed my mind to set up man page install rules for a tcl extension. Lesson learned.

no install rule for the man page.

There is not. It had not occurred to me that anyone would install a man page for a tcl extension. That's now on the list of TODOs.

After having looked at this: the legacy man page for sqlite's extension is essentially devoid of content so adds (IMO) no value for anyone tcl-savvy enough to be using this extension.

If you can convince me that it's worth installing, i'll re-add it to the 3.51+ builds, but i've currently no plans to do so.

For completeness's sake, here's the complete man page:

.TH sqlite3 n 4.1 "Tcl-Extensions"
.HS sqlite3 tcl
.BS
.SH NAME
sqlite3 \- an interface to the SQLite3 database engine
.SH SYNOPSIS
\fBsqlite3\fI command_name ?filename?\fR
.br
.SH DESCRIPTION
SQLite3 is a self-contains, zero-configuration, transactional SQL database
engine.  This extension provides an easy to use interface for accessing
SQLite database files from Tcl.
.PP
For full documentation see \fIhttp://www.sqlite.org/\fR and
in particular \fIhttp://www.sqlite.org/tclsqlite.html\fR.

There's nothing in there beyond a link which an internet search of "sqlite3 tcl" will find as the first result.

... http://www.sqlite.org/tclsqlite.html which provides useful information.

i'd argue that a doc file which contains only a link to what is exactly one click away from the home page (see the menu on the right) and is the top-most internet search result for "sqlite tcl" is not worth the maintenance hassle of re-integrating. There's literally nothing that man file would do except to waste the target system's storage space.

Now, if someone were to populate it (and maintain it), with actual how-to information, that would be another thing entirely, but a single hyperlink is not worth maintaining a man page for, especially when that link is otherwise so readily available to anyone who's looking for how to use it.

Perhaps the man page and doc folder should be removed, and the link should be added to the README.txt file

Done in trunk! That will show up in 3.51+, not 3.50.x patch releases (which are for fixes only).

Post-install test of package require sqlite3 3.50.0...

BTW: the post-install test will only fail if loading the module fails. All that test does is 'package require' using the configured tclsh. If it cannot be loaded post-install then we have perhaps selected an incorrect installation path. We take the first directory offered by Tcl's $::auto_path, which is what we've always done for the Tcl extension.

When upgrading a previous version the test will fail, as the new version is only in destroot, while the old version is installed under prefix.

Do you consider installation to the $DESTDIR/$prefix to be a bug? i don't but am willing to be convinced otherwise.

Edit: okay, i see now that the post-installation check can't really work when DESTDIR is set, unless the tclsh invoked happens to be under that dir. Suggestions on how to improve that would be welcomed. e.g. removing the post-install test when DESTDIR is set?

The present test will only give the correct result after the package is packaged from destroot and then activated.

The funny thing is that i've been using that test daily for months, on many OSes, and it "just works" :).

In other words, it makes no sense to run the current form of the test until the new package has replaced the old one in the install prefix (generally /opt/local for MacPorts).

Installation, in my experience, replaces the old one. There is no extra "activation step" in my world.

A quick patch fixes this problem, even with the old version still active:

That's not testing what needs to be tested. The post-install test is ensuring that the installed copy of the package can be loaded. That patch will load the one from the build dir (which is already tested by "make test").

i can provide a configure flag to disable the post-install test (edit: or auto-do-so if that environment can be reliably detected (how?)), but am not keen on outright removing it, as it works on every platform i've tested: a handful of Linux flavors, OpenBSD, HaikuOS, Cygwin, and Msys2.

A quick patch fixes this problem, even with the old version still active:

Counter-proposal:

Index: teaish/Makefile.in
==================================================================
--- teaish/Makefile.in
+++ teaish/Makefile.in
@@ -372,14 +372,19 @@
 	fi
 	$(INSTALL.noexec) "@TEAISH_TM_TCL@" "$(install-core.tmdir)/$(tx.tm.tgt)"
 @endif
 install-test: install-core
 	@echo "Post-install test of [package require $(tx.name.pkg) $(tx.version)]..."; \
+	set xtra=""; \
+	if [ x != "x$(DESTDIR)" ]; then \
+		xtra='set ::auto_path [linsert $$::auto_path 0 [file normalize $(DESTDIR)$(TCLLIBDIR)/..]];'; \
+	fi; \
 	if echo \
-		'set c 0; ' \
+		'set c 0; ' $$xtra \
 		'@TEAISH_POSTINST_PREREQUIRE@' \
-		'if {[catch {package require $(tx.name.pkg) $(tx.version)}]} {incr c};' \
+		'if {[catch {package require $(tx.name.pkg) $(tx.version)} xc]} {incr c};' \
+		'if {$$c && "" ne $$xc} {puts $$xc; puts "auto_path=$$::auto_path"};' \
 		'exit $$c' \
 		| $(TCLSH) ; then \
 		echo "passed"; \
 	else \
 		echo "FAILED"; \

Demo from another tree which uses that same makefile:

[stephan@nuc:~/f/tcl/teaish/teaish/example/hello]$ ../../configure --features --prefix=$PWD/p --with-tcl=$HOME/tcl/8.6
...
[stephan@nuc:~/f/tcl/teaish/teaish/example/hello]$ make install DESTDIR=$PWD/x
...
/usr/bin/install libhello0.1.so "/home/stephan/f/tcl/teaish/teaish/example/hello/x/home/stephan/tcl/8.6/lib/tcl8.6/hello0.1"
...
Post-install test of [package require hello 0.1]...
This file was activated using the -pkgInit.tcl flag to teaish-pkginfo-set. dir=/home/stephan/f/tcl/teaish/teaish/example/hello/x/home/stephan/tcl/8.6/lib/tcl8.6/hello0.1
passed

I've checked your version of the test, It passes cleanly, even with the older version of sqlite3-tcl still active.

However, I think running the test during this phase misses the whole point: Can tcl find the package and load it once it is installed? We currently are answering: Can tcl load the package at all? (my version of the test does the same thing, just from the build directory, rather than the destroot directory).

MacPorts allows for archives of multiple version of a package to exist. The user can only activate one of them, usually the current one. It is sometimes a good thing to be able to fall back to a previous version if there are unanticipated ABI breakages.

The test really should be run as a post-activation script. That means, that this test should not be run by the Makefile, but rather by the MacPorts Portfile. However, that is also tricky, because MacPorts port uses its own version of tcl (it is signed as part of the MacPorts package, and is usually an slightly older version, currently 8.6.14, vs. 8.6.16 for the package).

However, I think running the test during this phase misses the whole point: Can tcl find the package and load it once it is installed? We currently are answering: Can tcl load the package at all? (my version of the test does the same thing, just from the build directory, rather than the destroot directory).

The sole purpose of "make install"'s post-install check is to ease my mind during development. It does that, and there are no glaring downsides to how it does it, IMO.

The test really should be run as a post-activation script. That means, that this test should not be run by the Makefile, but rather by the MacPorts Portfile. ... However, that is also tricky...

Beyond support for long-conventional build vars like $prefix and $DESTDIR, the build process doesn't account for downstream packagers' needs, nor should it. That's all downstream voodoo to us.

Ours is "a" build process, not "the" build process. We can't possibly account for every "platformism" out there. If Package Repository X has special needs, then any related maintenance burden belongs in Package Repository X. It would be a simple matter to forego the included configure script and replace the makefile with a custom 10-20-line one which perfectly suits the packager's needs.

Just like the older TEA build, the new TEA(ish) build process is not specific to SQLite, but it's spun off as its own side-project, so any changes to the core behaviors provided by that framework (like "make install") need to be well-justified, as they can affect an arbitrary number of other tcl extensions which use that same framework.

No worries!

MacPorts automatically makes sure that the library (or any binary, for that matter) links to compatible libraries when it activates a package.. That's not quite the same thing as the original test, but should do.

So I think, I'll keep either one of the simple pre-package tests, or as is currently the case, disable the test altogether, when the next sqlite3 update comes along.