Tcl Source Code

View Ticket
Login
Ticket UUID: 926088
Title: test suite picks up old registry version
Type: Bug Version: obsolete: 8.5a2
Submitter: vincentdarley Created on: 2004-03-30 15:52:04
Subsystem: 53. Configuration and Build Tools Assigned To: davygrvy
Priority: 5 Medium Severity:
Status: Closed Last Modified: 2004-10-28 03:56:21
Resolution: Fixed Closed By: davygrvy
    Closed on: 2004-10-27 20:56:21
Description:
On Windows, if I do 'nmake -f makefile.vc test', the
test suite runs, but on the registry tests it always
picks up an older registry package somewhere on my
system and uses that instead.  This means that some
registry tests fail since subcommands are missing.

The test suite should ensure it sets auto_path/etc
correctly so that the build being tested is actually used.

Vince.

----

registry.test

==== registry-1.2 argument parsing for registry command
FAILED
==== Contents of test case:

    list [catch {registry foo} msg] $msg

---- Result was:
1 {bad option "foo": must be delete, get, keys, set,
type, or values}
---- Result should have been (exact matching):
1 {bad option "foo": must be broadcast, delete, get,
keys, set, type, or values

==== registry-1.2 FAILED


==== registry-12.1 BroadcastValue FAILED
==== Contents of test case:

    list [catch {registry broadcast} msg] $msg

---- Result was:
1 {bad option "broadcast": must be delete, get, keys,
set, type, or values}
---- Result should have been (exact matching):
1 {wrong # args: should be "registry broadcast keyName
?-timeout millisecs?"}
==== registry-12.1 FAILED


==== registry-12.2 BroadcastValue FAILED
==== Contents of test case:

    list [catch {registry broadcast "" -time} msg] $msg

---- Result was:
1 {bad option "broadcast": must be delete, get, keys,
set, type, or values}
---- Result should have been (exact matching):
1 {wrong # args: should be "registry broadcast keyName
?-timeout millisecs?"}
==== registry-12.2 FAILED


==== registry-12.3 BroadcastValue FAILED
==== Contents of test case:

    list [catch {registry broadcast "" - 500} msg] $msg

---- Result was:
1 {bad option "broadcast": must be delete, get, keys,
set, type, or values}
---- Result should have been (exact matching):
1 {wrong # args: should be "registry broadcast keyName
?-timeout millisecs?"}
==== registry-12.3 FAILED


==== registry-12.4 BroadcastValue FAILED
==== Contents of test case:

    list [catch {registry broadcast {Environment}} msg]
$msg

---- Result was:
1 {bad option "broadcast": must be delete, get, keys,
set, type, or values}
---- Result should have been (exact matching):
0 {1 0}
==== registry-12.4 FAILED


==== registry-12.5 BroadcastValue FAILED
==== Contents of test case:

    list [catch {registry b {}} msg] $msg

---- Result was:
1 {bad option "b": must be delete, get, keys, set,
type, or values}
---- Result should have been (exact matching):
0 {1 0}
==== registry-12.5 FAILED
User Comments: davygrvy added on 2004-10-28 03:56:21:
Logged In: YES 
user_id=7549

committed to HEAD.

davygrvy added on 2004-10-27 04:32:50:

File Deleted - 100726: 



File Added - 106589: patch.txt

davygrvy added on 2004-10-27 04:32:47:
Logged In: YES 
user_id=7549

here's another patch..  Seems more complete and tested.
It still needs win/Makefile.in and win/makefile.bc changes.

davygrvy added on 2004-09-08 14:16:02:

File Added - 100726: patch.txt

davygrvy added on 2004-09-08 14:16:01:
Logged In: YES 
user_id=7549

Here's a patch for it.  win/Makefile.in and win/makefile.bc
changes missing.  We need those before I can commit this.

vincentdarley added on 2004-07-02 23:56:36:
Logged In: YES 
user_id=32170

There seem to be some good solutions suggested here.  Any
chance that one of them can be checked in so this report can
be closed?

vincentdarley added on 2004-04-23 19:16:40:
Logged In: YES 
user_id=32170

Note: the same problem may well be true of the 'dde' package
as well, just that hasn't changed recently?

dgp added on 2004-04-13 00:26:42:
Logged In: YES 
user_id=80530


An excellent observation!

That will/would work even
better with registry packaged
as separate source/docs/test
under a tcl/pkgs/ directory.

davygrvy added on 2004-04-10 06:51:22:
Logged In: YES 
user_id=7549

Personally, I've found -load and -loadfile to effective in 
sqaushing this for other projects.  Example:

test : release
$(TCLSH) .\tests\all.tcl $(TESTFLAGS) -loadfile <<
load [file normalize $(IOCPLIB:\=/)]
<<


And in the top of my *.test files I add this line:

::tcltest::loadTestedCommands

dgp added on 2004-04-01 02:13:37:
Logged In: YES 
user_id=80530

Ick.  I'd forgetten the detail that
the pkgIndex.tcl file and the
actual DLL it is paired with are
in different source directories.

Looks like the pkgIndex.tcl file
for registry can't really function
until the package is installed.

the original strategy of a direct
[load] got around that.  Is there
any way to make that [load]
effective even with an existing
registry package already loaded?
can [package forget] help?


Really would be better to get
registry in a directory by itself
under a proposed "pkgs" directory.

kennykb added on 2004-04-01 00:58:00:
Logged In: YES 
user_id=99768

registry.test appears to be doing The Right Things;
instead 'make test' itself appears to be the trouble spot.

What's happening here is that registry.test contains its own
explicit [load] of the registry package, but that [load] is
not effective, because the registry package has already been
loaded by the [package require] in msgcat.tcl.

The way to fix it, according to dgp, is to change the
'test:' rule in the makefile to set TCLLIBPATH so that both
the 'library/' directory and the directory in which tclregXX.dll
was built appear in the path.  That way, [package require]
will hit the newly-built versions rather than anything that
is installed.

dgp's newsgroup posting, while it would address the
specific failures, does not address the problem that the
package-under-test is not the one that is loaded.

Note that both configure/make and makefile.vc have the
problem.

dgp added on 2004-03-31 08:45:17:
Logged In: YES 
user_id=80530

...specifically I like the strategy in:

http://groups.google.com/groups?selm=slrnb3ca3s.liu.dgp%40clover.cam.nist.gov

dgp added on 2004-03-31 08:28:44:
Logged In: YES 
user_id=80530


auto_path setting are good,
but best to use constraints on
the tests as well.  Ought to be
some history on this subject
in c.l.t....

Attachments: