[Tcl-bugs] [ tktoolkit-Bugs-765642 ] [load] Tk needs Tcl's --prefix

[SourceForge.net <no...@so...>]

Bugs item #765642, was opened at 2003-07-03 18:30
Message generated for change (Settings changed) made by dgp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=765642&group_id=12997

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 74. Application Embedding
Group: obsolete: 8.4.3
Status: Open
Resolution: None
>Priority: 8
Private: No
Submitted By: Don Porter (dgp)
Assigned to: Don Porter (dgp)
Summary: [load] Tk needs Tcl's --prefix

Initial Comment:

During a [load <Tk>], the Tk_Init() routine runs.

In turn, it tries to eval the [tcl_findLibrary] command
to find the installed tk.tcl file.

If Tk was installed with TK_PREFIX the same as
Tcl's TCL_PREFIX, then this will succeed.

However, if Tk is installed somewhere else, and
a Tcl interpreter tries to [load] it, there will be an
error as Tk is unable to find the tk.tcl file.  This means
that Tk will not work correctly since it did not get
initialized.

There are a number of partial solutions possible.

Tk's configure/build/install could be constrained
to force TK_PREFIX to be the same as TCL_PREFIX.
However, that just means the Tk will be [load]able
in the Tcl installation it was configured against.
The bug will remain when trying to [load] the same
Tk shared library in a different Tcl installation.

As requested in Tcl Feature Request 695441,
[tcl_findLibrary] could be extended to also search
directories on the auto_path.  This would workaround
this bug in the most common case where the [load]
is wrapped inside the mechanics of [package require],
and the search for require-able packages is done
using [tclPkgUnknown] -- the default [package unknown] 
handler -- which is influenced by the value of ::auto_path.
This will not fix the bug for direct [load]s though.

Ultimately, the problem is that Tk_Init() needs a
better tool/strategy for finding its script library than
[tcl_findLibrary] is capable of providing.  Since the
Tcl world now includes virtual file systems, the
ultimate solution may require embedding Tk's
script library into the binary library itself as an
internal file system so that this problem of finding
and joining two separately installed pieces of Tk
just goes away.

Short of that, a revised installation strategy that
installs the Tk script library under TK_EXEC_PREFIX
in the same directory as Tk's pkgIndex.tcl file
would also be a solution.  There would be no need
for a [tcl_findLibrary] call.  The pkgIndex.tcl file
would just arrange for

    source [file join $dir tk.tcl]

to be part of Tk's package loading script.  The cost
of that solution is that on multi-architecture
installations,
each architecture gets its own copy of the Tk script
library installed -- costing some disk space and
costing some maintenance effort for those installations
that make customizations to the script library.

----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2004-11-15 18:21

Message:
Logged In: YES 
user_id=80530


If Tk is updated to call 
Tcl_RegisterConfig, we
could close this, I think.

Possible for Tk 8.5a2 ?

----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2004-08-31 09:36

Message:
Logged In: YES 
user_id=80530

[tcl_findLibrary]'s search path has
been expanded to include the $::auto_path
which should solve this for the common
[package require Tk] situation.

[tcl_findLibrary] also checks the
scriptdir,runtime value registered
by a package with Tcl_RegisterConfig.
See TIP 205 for a proposal to have Tk
make use of this new config registration
interface.

----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2003-10-06 12:59

Message:
Logged In: YES 
user_id=80530


For 8.4.5, changed Tk's configure
to default TK_PREFIX to the
value of TCL_PREFIX, and to
print a warning if the user selects
a configuration where they are
not the same.

Leaving open for a more flexible fix.

----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2003-07-03 23:15

Message:
Logged In: YES 
user_id=80530


Another solution opens up in Tcl 8.5.
The C API provided by TIP 59 could
be used to embed in the Tk shared
library the configured directory for
storing Tk's script library.  Then the
[tk::pkgconfig] command could
retrieve that value and use it to
initialize tk_library.

More generally, [tcl_findLibrary foo ...] could
be extended to call the foo::pkgconfig
command and retrieve the value of
a conventional key ("scriptdir,runtime" ?)
and add it to the search path.

----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2003-07-03 19:17

Message:
Logged In: YES 
user_id=80530

er, a better way to accomplish the last approach
is to add

    set ::tk_library $dir

to Tk's package loading script rather than
directly [source] tk.tcl

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=765642&group_id=12997