#2276 Tcl_InitStubs calls demand lockstep with Tcl

[Don Porter]

All the Tcl_InitStubs() calls
in the Tk HEAD look like this:

Tcl_InitStubs(interp, TCL_PATCH_LEVEL, 1)

Even ignoring the controversy over how
-exact matching has been revised (Tcl
Bug 1578344), this call results in too
tight a demand for Tcl release compatibility.
If no changes are made to the way the codes are currently written, we will one day compile some
Tk source code against an 8.5.1 tcl.h file, and
the resulting shared library will only be able
to [load] into an interp in the range 8.5.1-8.5.2.
In particular, this shared library would
not [load] into a Tcl 8.5.2 interp, which
by tradition would be the next release of Tcl.

The implication is that a Tk build is only
good for a single release of Tcl, which
means the use of stubs is pretty nearly
pointless.

I think the proper calls that would take
advantage of the special provisions
made for -exact matching ought to be:

Tcl_InitStubs(interp, TCL_VERSION, 1)

Combining that call with the special -exact
matching rules would produce a shared library
that will [load] into any Tcl 8.5* interp, which
is the level of release compatibility we have
supported between Tk and Tcl up to now.

Feel free to drop in the chat if further
discussion is needed to understand me.

If it's really intended to lockdown each
Tk release to exactly one Tcl release, we
really ought to publicize that. I'll
try my best to talk you out of it.

[Don Porter]

Logged In: YES
user_id=80530
Originator: YES

Note that the lockstep currently
enforced is that a Tk shared library
can only be [load]ed into the same
release of a Tcl interp as the version
of the Tcl header file it was compiled
against. This may or *may not* be the
same release number as Tk.

If lockstep really is the intent here,
then the compile time checks in tk.h
should be extended to force complete
matching, so that a match with tcl.h
and a matching release number are the
same thing.

[Don Porter]

Logged In: YES
user_id=80530
Originator: YES

Fixed in HEAD.