Abstracted from Tcl 9.0 WishList in order to make that page easier to read...
Better Support for static packages. Static packages should not need a pkgIndex.tcl somewhere on disc. And, instead of , perhaps a special command could be provided.
DKF - What's wrong with:
proc ::tcl::loadStatic {package} {
uplevel #0 [list load {} $package]
}That's not even backwards-incompatible!
Volker - I didn't know about that one. Nevertheless, what I wanted is some loading mechanism for systems that don't support the shlib stuff.
DKF - Well, we've done a lot to support shared libs better across platforms (load, stubs, packages, etc.) and there is always the mechanism outlined above for loading statically linked packages into a Tcl interpreter (provided they've registered themselves with Tcl_StaticPackage() of course.) What else could you possibly want?
Volker - A tcl that is easy to port to VxWorks, eCos, ThreadX and whatever else is around for embedded systems. In many cases you can count your blessings if your compiler supports ANSI-C syntactically. Anyway, the end result usually is a single executable that gets loaded in the on-chip-flash of your system. main() will be entered at switch on and left at switch off time. Forget everything about file systems, clock seconds or kinky things like modules, shlibs/dlls or other "newfangled desktop OS stuff". -)
DGP - I don't think there's really a request for a worthwhile new feature here. I think this is really a matter of recording and using best practices with the existing interfaces when embedding static packages.
Aha! Working through an example always leads to clearer understanding. I think this RFE refers to the problem that there is no way to discover what package (in the sense of the [package] command), if any, is provided by a particular static library registered with Tcl_StaticPackage().
That is, after the call
Tcl_StaticPackage(NULL, "Foo", Foo_Init, Foo_SafeInit);
the Tcl library has enough information registered to make the command
[load {} Foo]work in any interp, but it does not have any information registered about whether the Foo_Init and/or Foo_SafeInit routines contain calls to Tcl_PkgProvide(), and if they do, what version(s) of what package(s) they provide. Without that additional information, the appropriate [package ifneeded] entries cannot be constructed to support the [package require] of the package provided by the static package.
One prior attempt to address this is Tcl Patch 403531 [L1 ], but that was a misfire.
DKF: It's a shame that it's called Tcl_StaticPackage since that is what is confusing. Tcl_StaticLibrary would be better. (Why is that function in the stubs table? Should a dynamically-loaded library ever call it?)
DGP: Certainly, the typical, normal, recommended uses of Tcl_StaticPackage are all in AppInitProc's, so they don't need it as a stub. The docs recommend strongly against and calls to Tcl_StaticPackage within a Pkg_Init routine, because the initialization of a library should not care how it is linked within the app. Whether or not I could eventually strain my thinking enough to invent a use for a Tcl_StaticPackage stub, I'm not certain. (A dynamically loaded package that carries another static package within itself? Can't think how that would be useful.)
APN: In response to DGP above, I have a potential use for static packages embedded in a dynamic extension. Some "modules" within TWAPI are relatively expensive to initialize. I'm contemplating presenting them as separate (but embedded) packages within TWAPI. There are several ways of doing this but using Tcl_StaticPackage seems the simplest and most natural to me. Within the Twapi_Init routine I would call for example Twapi_StaticPackage(interp, "Twapi_wmi", Twapi_wmi_Init, NULL). Does this seem a reasonable use?