On 2025/01/14 17:38, Stuart Cassoff wrote:
> Tcl 9 was released this year and I'd like to add it to the ports tree soon.
> 
> Here's an updated tcl.port.mk and diff.

same issue with mangled file/diff as jimtcl.

from webmail, you probably need to send the diff as an attachment
(and if it still manages to mangle that, perhaps as a gzipped
attachment).

> One thing I'd like is to have "9" instead of "9.0" in files and dirs, like 
> "tclsh9" instead of "tclsh9.0", the port dir itself would be "tcl9".
> A future Tcl 9.1 would simply replace any 9.0.
> I think it would be good/possible to just try to have only one Tcl 9, and 
> eventually only one Tcl: 9.
> A port would still have to set MODTCL_VERSION to "9.0", primarily since 
> having "9" as the value of a subst var will wreak havoc with plists!
> To facilitate that, I've copied the idea of default versions vars from the 
> python.port.mk.

python.port.mk still has some cruft from old things and I wouldn't
really recommend it as a good place to copy from.

re MODPY_DEFAULT_VERSION_x, it isn't really useful any more (_3 is
pointless now that the various lang/python/3.x have been replaced with
lang/python/3, and _2 is never going to change, so they're surplus to
requirements) - plus they ended up used incorrectly in several places
so I have it on the cards to retire them at some point when I feel like
untangling it. I'd suggest having an exit strategy if you want to add
similar to tcl.port.mk (I think I'd probably add MODTCL_DEFAULT_VERSION_8
for now, set MODTCL_VERSION=${MODTCL_DEFAULT_VERSION_8} in the various
existing ports, and switch MODTCL_VERSION in tcl.port.mk to 9.0 or 9.

only one port, comms/hamlib, uses MODTCL_VERSION in the PLIST so I'm not
sure it needs to be in SUBST_VARS at all.

if it's correct that hamlib installs to lib/tcl${MODTCL_VERSION}
and you want to handle that via the module, you can set a new variable
e.g. MODTCL_TCLVERLIB=lib/tcl${MODTCL_VERSION}, add that to SUBST_VARS,
and regenerate hamlib's PLIST. even with MODTCL_VERSION=9 that's not
likely to cause problems with PLIST substs due to the longer match.
alternatively, just hardcode the version in hamlib's PLIST, it's only
one port so easy enough to update by hand.

and of course if hamlib should really install to lib/tcl <no version>
then that's even easier.

Reply via email to