Menu
▾
▴
#148 Index script preference for debug Tk
When both debug and non-debug Tk
are installed, the generated index scripts
allow either one to successfully [load]
into tclsh. Which one you get from a
[package require Tk] is currently
quasi-random, depending on the order
in which [tclPkgUnknown] [source]s
the pkgIndex.tcl files.
This patch forces a preference for
the debug-enabled Tk when Tcl
is also debug-enabled. David
Gravereaux reports he finds this
combination useful when stepping
through Tcl/Tk applications.
When Tcl is not debug-enabled,
the choice for Tk remains
quasi-random even after this patch,
but that seems OK. Either Tk will
work, so either satisfies the
[package require].
This patch changes only win/Makefile.
If it is accepted, similar changes should
be made to the alternative makefiles.
Logged In: YES
user_id=7549
Is this patch saying alternate build flavors of Tk should install
to a different directory? As in:
lib/tk8.5
lib/tk8.5dbg
lib/tk8.5thrd
lib/tk8.5compstat
lib/tk8.5dbgthrd
lib/tk8.5memdbg
lib/tk8.5memdbgthrd
..etc, etc..
Logged In: YES
user_id=80530
Essentially yes. tk/win/Makefile
installs whatever variant was built
into $PKG_INSTALL_DIR which
is defined as
$(LIB_INSTALL_DIR)/tk$(VERSION)$(TK_DBGX)
so there as many distinct install directories
as there are variations of $TK_DBGX.
For variants not distinguished by TK_DBGX,
let's discuss further. Which of these variants does
it make sense to have concurrently installed?
What distinct compatibility needs do they
have with each other, and with Tcl and other
libraries?
See also: http://wiki.tcl.tk/4312
Logged In: YES
user_id=7549
C:\PROGRA~1\Tcl\bin>dir /b wish85*
wish85.exe
wish85g.exe
wish85t.exe
wish85tg.exe
C:\PROGRA~1\Tcl\bin>dir /b tk85*
tk85.dll
tk85g.dll
tk85t.dll
tk85tg.dll
The g one is straight symbols without memdbg nor compstats,
but we wouldn't know this from the suffix. I only have one
lib/tk8.5 directory.
Logged In: YES
user_id=7549
An order of preference might be:
if Tcl is not threaded and a threaded Tk exists, prefer the
threaded Tk. The behavior of the TSD and mutexes is
determined by the Tcl core the extension is loaded into. IMO,
all extensions should be compiled for thread support by
default.
If Tcl has symbols, prefer a symbols Tk, but fallback to non-
symbols when not available.
memdbg and compstats are a grey area. The prefix is the
same for symbols. 'g' has something regarding debugging, but
can not be determined.
Logged In: YES
user_id=80530
What is the difference between
a --enable-threads build of Tk
and a --disable-threads build
of Tk. Are the DLLs produced
really different? If so, is there
anything one can do that the
other cannot?
Ideally, I think I'd like Tk not
to care about threads. Short
of that I'd like a better understanding
about why it does care.
Logged In: YES
user_id=7549
Tcl_GetThreadData, Tcl_MutexLock, Tcl_MutexUnlock and a
few other bits actually have an implimentation when the core
is threaded. That's about it. When not threaded,
Tcl_GetThreadData just makes or gets an instance of the
ThreadSpecificData struct but isn't associated to the calling
thread (just one).
Again, behavior of threading is determined by the core the
extension is loaded into. If a threaded Tk loads into a non-
threaded Tcl, no thread specific data is maintained and
mutexes don't work. As far as I know, this is absolute.. I
don't know if there are any exceptions.
Logged In: YES
user_id=80530
It looks to me like those public Tcl
routines are all in the public stubs
table, so the Tk library, built
with -DUSE_TCL_STUBS is
going to look the same with either
configuration, isn't it?
In other words, if tk85t.dll and tk85.dll
are byte for byte identical, I don't
see the benefit in having both names
(or even recognizing a --enable-threads
configuration option for that matter).
As far as I'm concerned the fewer variants
to keep track of, the better.
I'll take a brief look at the Tk code myself
to see if I can find anywhere that a
--enable-threads configuration actually
has an effect.
Logged In: YES
user_id=7549
Pretty close. Tcl_Mutex(un)lock are macros and empty
without #define TCL_THREADS for the Tk build. I don't know
off-hand about the TCL_TSD_INIT macro.
It would be nice if the TCL_TSD_INIT macro moved to tcl.h
from tclInt.h, but that's another issue and very minor.
Logged In: YES
user_id=80530
ok, I slowly see more. If Tk ends
up paired with a --disable-threads
build of Tcl, then all these routines
are no-ops anyway, so using macros
to remove the calls completely changes
nothing and saves some time, and
that's what --disable-threads build of
Tk does. So the --enable-threads
and --disable-threads builds are different.
Either Tk build will [load] into either
Tcl variant, it appears, but the only
way the combination will support
threads is if both are --enable-threads
configurations.
Logged In: YES
user_id=80530
weird, apparently on Unix, Tk's
configure doesn't honor the
--enable-threads option, but takes
whatever was set in the Tcl build
from the corresponding tclConfig.sh.
Not clear what effect that has on
[load]-ability into a different Tcl.
(binary extension distribution anyone?)
On Windows, though, looks like it
does respect the --enable-threads choice.
Better take this to e-mail or chat, or just
individual study.
Logged In: YES
user_id=7549
Here's something I'm doing for Itcl. The Stubbed dll can load
into any core 8.1+ and there's also an 8.0 one, too.
What do you think? Tk needs to match itself to the core
version.
pkgIndex.tcl for beta Itcl3.3b1
Logged In: YES
user_id=80530
this will be moot once
Patch 1081595 kills
TCL_DBGX, right?