Tcl Source Code

Sometimes it is important
to test an extension in the
same version of Tcl it was
configured for.  (Or at least
not an earlier, possibly incompatible,
release).

TEA_PROG_TCLSH appears to
just crawl through a search path
looking for any programs named
tclsh* .  This could easily be an
earlier release of Tcl, and
conceivably not a Tcl interpreter
program at all.

Would be an improvement for
TEA_PROG_TCLSH to try
to evaluate [info tclversion]
in the program it finds.  This 
would allow verification that
the program is in fact a Tcl
interpreter at all, and that it
provides a Tcl version that satisfies
the TCL_VERSION value in
the tclConfig.sh file that is
in use.

This has bitten when people
try to test the trofs extension,
where they configure against
a Tcl 8.5 tclConfig.sh and
header files, but attempt to
run the test suite in a Tcl 8.4
tclsh, which fails.

Logged In: YES 
user_id=90858

Added to CVS on 2005-07-26. Checked into tclconfig/,
sampleextension/, and thread/ packages. The only change an
extension will need to deal with
is creating a pkgIndex.tcl.in file and generating a
pkgIndex.tcl and configure time. This is needed since
TCLSH_PROG should not be used
for generation of things at build time. The only thing a
version check
would do is check that the version in tclConfig.sh is the
same as the
version of the tclsh installed in the bin dir. But, the code
really does
that already since the path of the tclsh in the bin dir is
deduced via
the TCL_VERSION and TK_VERSION flags found in either
tclConfig.sh or tkConfig.sh. Also, you can't assume that the
tclsh
executable can be run to do a version check, that will not
work in
a cross compile.

Logged In: YES 
user_id=80530


Yes, I like that much better.  Thanks.

An additional version number check
might offer even more safety, but
the patch attached is a fine improvement.

Guess we should apply it to find out
who prefers the existing TEA_PROG_TCLSH. :^)

File Added - 143294: sampleextension2.patch

Logged In: YES 
user_id=90858

OK, how about the following patch? It nukes BUILD_TCLSH and
sets TCLSH_PROG to either the build tclsh or the tclsh installed
into the bin dir. There is no PATH searching in this
approach so no
chance of picking up a bad tclsh or wish shell.

Logged In: YES 
user_id=80530


We must distinguish between
Tcl build time and extension build time.

TEA is for extensions.  When my extension
is using TEA to set up things for building
the extension, there's no reason to expect
there's any build directory around from the
building of Tcl.  In the normal case there is
no "tclsh that was just built".  But there ought
to always be "a tclsh that corresponds to the
tclConfig.sh I am using."

If TEA_FOO_TCLSH have been copied
over from their SC_FOO_TCLSH
counterparts uncritically without accounting
for the different needs of extension from
the needs of Tcl's own build scripts, then
yes perhaps there's some undoing to be done.

The particular need I have for a more
appropriate TEA_PROG_TCLSH is to
find a program suitable for running my
extension's test suite.

Logged In: YES 
user_id=90858

TEA was using TCLSH_PROG for two different things.
It could be executed at build time to generate a pkgIndex.tcl
or it could have been used to run the tests. The change splits
this functionality into two macros.

The only other logical thing would be to remove TCLSH_PROG
entirely and make sure that the tclsh executable was only
used to run tests (when not cross compiled). When it comes
to running the tests, the only logical thing to do is run them
against the tclsh that was just built in the Tcl build dir.

Logged In: YES 
user_id=80530


re-opening.

The additional TEA_BUILD_TCLSH
macros may help someone, but it
doesn't fulfill the needs of this
feature request.

As an extension author, I need a
reliable and simple way to say
"give me a tclsh that corresponds
to the tclConfig.sh file I'm using".
My original complaint was that
TEA_PROG_TCLSH doesn't
do that reliably.

Now TEA_BUILD_TCLSH arrives
and also doesn't do that reliably
(why would I assume a build
directory of Tcl is even on the system?)

This is a step backwards.  TEA should
give me one thing that works, not two
half-measures that every extension author
has to assemble (mostly incorrectly).

File Deleted - 142320:

Logged In: YES 
user_id=90858

This is now fixed in the HEAD and the 8.4 branch.
See Tcl patch 1244153 for all the details and patches.

File Added - 142320: thread2.patch

Logged In: YES 
user_id=90858

This is a serious issue. The TEA_PROG_TCLSH macro is lacking
a way to find the tclsh executable in the build directory.
People are
using the macro for two different things. First, to find a
tclsh on the
system. Second, to find the tclsh in the build dir. I have
attached
a patch that fixed the thread package WRT this tclsh search
issue.
Another possible approach would be to create two macros, one
that
searches the PATH (and NOT in the build dir) and another
that just
searches in the build dir. Note that the current macro
mistakenly assumes that tclsh would even be built in the
build dir when the child package is getting configured.