I'm going to open a ticket for Rivet 2.1.0. The problem is serious but
it doesn't make Rivet unusable anyway.
Short description: building Rivet with
--enable-import-rivet-commands doesn't guarantee commands in librivet
are actually imported into the global namespace.
Longer description: User might be believing the whole command set was
imported into the global namespace whereas it's not true. Commands in
librivet must be loaded reiterating a namespace import command. The
problem has been fixed in trunk by exchanging the order with which
package Rivet and package rivetlib are required (requiring package Rivet
runs init.tcl and imports into global namespace the commands from ::rivet).
I also renamed package RivetTcl (rivet/init.tcl) as package 'Rivet'. In
Rivet<=2.0 librivet provided package Rivet and thus there are scripts
around the are requiring it. Since the name Rivet seemed inappropriate
for a library of standalone code it was renamed as 'rivetlib' and that
package disappeared. After all init.tcl prepares the basic Rivet Tcl
stuff I thought it could be the script providing a 'Rivet' package thus
preserving those scripts requiring it.
Temporary workaround for the current 2.1.0 code: package 'rivetlib' must
be required in a child initialization
eg:
RivetServerConf ChildInitScript "package require rivetlib"
RivetServerConf ChildInitScript "namespace import -force ::rivet::*"
I'm terribly sorry. It wasn't difficult to find this out, still writing
a test for it is impossible as the controlling parameters are set
running 'configure', not in the configuration...
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
