[Tcl-bugs] [ tcl-Feature Requests-695441 ] tcl_findLibrary does not look in $::auto_path

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

Feature Requests item #695441, was opened at 2003-02-28 23:09
Message generated for change (Comment added) made by dgp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=360894&aid=695441&group_id=10894

Category: 37. Init - Library - Autoload
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe English (jenglish)
Assigned to: Don Porter (dgp)
Summary: tcl_findLibrary does not look in $::auto_path

Initial Comment:
The tcl_findLibrary procedure does not check the
directories listed in $::auto_path when looking for the
specified initialization script.

This means that a combined script/binary package which
calls tcl_findLibrary in its _Init() routine might not
be able to find its own library, even though Tcl's
package mechanism was able to find the binary library.

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

>Comment By: Don Porter (dgp)
Date: 2003-07-03 18:55

Message:
Logged In: YES 
user_id=80530

see also Tk Bug 765642

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

Comment By: Don Porter (dgp)
Date: 2003-04-16 17:03

Message:
Logged In: YES 
user_id=80530


FWIW...

I notice that on Max OS X only, the ::tcl_pkgPath
is also searched.  This seems like a half-fulfillment
of this feature request on a single platform.

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

Comment By: Joe English (jenglish)
Date: 2003-03-03 18:56

Message:
Logged In: YES 
user_id=68433

Calling tcl_findLibrary from the package _Init() routine is
useful since it works for statically loaded as well as
dynamically loaded packages.  Plus, it provides useful hooks
for overriding the library path from the environment (for
e.g., debugging) and from the application (for e.g.,
tclkits).

BTW, I agree that the script and binary parts should always
be installed in the same place.  However, for
statically-linked, statically-loaded packages there might
not be a separate binary part (or even a pkgIndex.tcl).

Basically: if the binary part loads the script part, the
package can work as a Tcl_StaticPackage() or be dynamically
loaded with no code changes.  The other way around, it
can't.

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

Comment By: Don Porter (dgp)
Date: 2003-03-02 21:01

Message:
Logged In: YES 
user_id=80530

my strong preference is that no new package 
uses [tcl_findLibrary], and packages that
currently use [tcl_findLibrary] should try to
move away from it.

[tcl_findLibrary] exists to solve a problem that
packages are much better off just not
creating for themselves in the first place.

For your example, just be sure to install 
all files of Foo 1.0 [*] -- libFoo.so, fooInit.tcl,
and pkgIndex.tcl  -- all in the same installation
directory.  Then, pkgIndex.tcl should contain:

package ifneeded Foo 1.0 [list source [file join $dir
fooInit.tcl]]

And fooInit.tcl should contain:

load [file join [file dirname [info script]] libFoo[info
sharedlibextension]] Foo

Since your package includes binary files, it should
be installed only on an appropriate platform, either
under TCL_EXEC_PREFIX, or somewhere else
that will be placed on auto_path only on appropriate
platforms.

I believe this approach is what TEA2 recommends.

The older style of installing binary parts under
TCL_EXEC_PREFIX and cross-platform parts
under TCL_PREFIX is what led to the need
for [tcl_findLibrary] to allow the package to find
its missing half.  The only benefit of that scheme
was to save disk space on file servers serving
multi-platform clients, and that's largely an
optimization of a bygone era.  Much better for
runtime sanity and for uninstall capability to
put all parts of an installed package in just
one place.  

[*] FWIW, I'd rather you named the package
"foo" rather than "Foo".

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

Comment By: Joe English (jenglish)
Date: 2003-02-28 23:20

Message:
Logged In: YES 
user_id=68433

An example is probably in order:

Suppose Foo 1.0 contains libFoo.so, fooInit.tcl, and
pkgIndex.tcl, where pkgIndex.tcl says:

package ifneeded Foo 1.0 [list load [file join $dir
libFoo[info sharedlibextension]]]

and Foo_Init() Tcl_Eval()s a startup script containing

tcl_findLibrary Foo 1.0 1.0 fooInit.tcl FOO_LIBRARY 
Foo_Library

If Foo1.0 is installed in one of the standard places
(according to tcl_findLibrary), this will work.  If it's
stored in a nondefault location, [tclPkgUnknown] can find
out about the package if $::auto_path is extended, but the
package will still fail to load since tcl_findLibrary
doesn't look in the same place(s) as [tclPkgUnknown].

Or is this an improper use of tcl_findLibrary?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=360894&aid=695441&group_id=10894