On 2026/07/05 10:19, Stuart Cassoff wrote:
> Intro:
> Tcl extensions compiled for Tcl 8 and 9 differ
> for the most part in shared libraries.
> Executable scripts and examples would differ by shebangs.
> Any extension config files would conflict by name.
> All other files would be the same.
>
>
> Can a Tcl extension be built for both Tcl 8 and 9 in one Makefile?
> No, not really.
>
> Tried:
> * Using Tcl 9, an extension lib can be built for Tcl 8.
> Done in 'post-install', hacky and fragile, brings in a
> Tcl 9 dep for the Tcl 8 version (extra dep for current users),
> and doesn't provide more than the .so. No tests or anything.
> * Port hackrobatics to build both Tcl 8 and 9 versions at the
> the same time. Highly unsatisfactory and a bit silly.
> * One tcl9 subdir with the top Makefile being the main Makefile
> but also declaring a tcl9 subdir. Convoluted and didn't work!
>
> Building the port twice would yield the best result for each.
>
> I not to create a new dir and a whole new port for Tcl 9.
> Ultimately I gave in, and this way involves two new dirs.
This with ports/x/y/tcl8 and ports/x/y/tcl9 and various duplication
and fiddling with Makefile.inc feels particularly awkward, especially
when it needs replicating for every Tcl extension port.
It should be possible to do this with non-conflicting flavours of the
same port, similar to how python ports used to handle py2 + py3. The
difference compared to old python being that with this, one would
need to depend on the other, but I don't think that's a problem.
(The code supporting that in python.port.mk has since been removed
because the few remaining py2 ports either need to be in a different
version than the py3 equivalent, or there is no py3 equivalent,
so no need for the complication any more).
Most of the mechanism would be common to all Tcl extension ports
so could go in lang/tcl/tcl.port.mk so it's mostly one-time work to
do the setup there, with smaller changes to the individual ports as
they're moved across to it.
For the files which need to be present in only one of the flavoured
packages, I'd use the SUBST_VARS trick with a variable that defined to
either "@comment " or "" and use that to prefix those files in PLIST so
a single PLIST can be shared between the flavours. Other differences in
PLISTs are mostly going to be formulaic so you'd have e.g. for these
: libxyz123.so, libxyz123.so.0.0 and libxyzstub123.a.
: libtcl9xyz123.so, libtcl9xyz123.so.0.0, and libxyzstub.a.
you could set this in the tcl-xyz port
MODTCL_LIBV= 123
and in the module, other vars depending on the flavour (tcl8/tcl9),
to either of
MODTCL_EXTLIB= libtcl9
MODTCL_STUB= stub.a
MODTCL_EXTLIB= lib
MODTCL_STUB= stub${MODTCL_LIBV}.a
and similar for things like the path to *Config.sh files etc.
> This could be also flipped around, with the Tcl 9 version being the
> "main" and the Tcl 8 version being dependent.
> Might be more future-looking?
yes.
> Drawback is Tcl 8 users will also get the Tcl 9 version.
this does not seem a problem to me.
