'''an absence of magic, and no policy''' This was all lifted [http://trixie.triqs.com/pipermail/starkit/2002-July/000089.html]: There is no presupposition about how your files are arranged other than that the top level main.tcl is to be interpreted at launch. Unlike some other wrapping methods there isn't an enforced or assumed layout. The above is worth repeating, IMO. All a starkit does, is contain a dir hierarchy (even if just a flat one) which gets "mounted". That mount point happens to be the same spot as the starkit itself - in other words, file "/path/to/my/starkit.kit" ends up becoming *dir* "/path/to/my/ starkit.kit/" while in use, with things like "/path/to/my/starkit.kit/ lib/" being a preferred place to put packages, because that's what "starkit::startup" will set up for you, but it's all 100% wide open and totally scripted/inspectable. ''[escargo] -- there appear to be some accidental line breaks that add spaces to the pathnames in the viewable version of this page. I don't want to change them, but perhaps the knowledgable people could check and then fix them if appropriate. This remark could then be removed.'' ---- This is quite true - but I'll add the comment that the "starkit::startup" procedure that is usually invoked from the main.tcl does add the /path/to/my/starkit.kit/lib directory to the auto_path. So, although there isn't any enforced structure it sure is convenient to just drop packages into .../lib and have them available in your application - [stevel] [Ro]: yep steve you're right on the mark. It does say that in the paragraph that I lifted from [Jean-Claude Wippler] and [Steve Blinkhorn], but I'm glad that you expounded on that fact. A nice standard structure is easier to use, because you know that ''it works''. ---- [CMCc] There's a downside, or at least niggle, with starkits: making loadable binary extensions (like kitten, but less ambitious) is a black art. First problem is that starkit's tcl interpreter is a statically linked binary, so you can't expect a libtcl .so to be in your path. Second problem is that any library that is available won't have the same name at compile time as it has at runtime, which can make compilation relatively hard. I would appreciate any assistance with these problems. [LV] has this page http://mini.net/tcl/3795 for discussion and consideration. 08feb03 [jcw] - Your perception of "black art" is something I would very much like to help change. If it is, then starkits have failed to deliver, IMO - it should not be tricky, or even confusing. There are really only two stumbling blocks I know of: * shared libs *have* to be compiled with stubs (-DUSE_TCL_STUBS and -ltclstub8.4) * paths need to be relative far more often - i.e. using idioms such as load [file join [file dirname [info script]] blah].so The former is gradually becoming the norm. It has been in Tcl since 8.1, and solves a couple of issues along the way, so I'm sure it is just a matter of time to see more and more extensions compiled that way. This addresses your point of "libtcl.so" not being around: correct, because with stubs, they no longer play a role. The latter is actually quite valuable - you are being forced to consider that your code may not run in the same place as you are developing it in. It now becomes an issue slightly sooner in the lifetime of a software project. The name itself changes if yuou are referring to VFS's default behavior of copying a shared lib out to temp before running it. But if that is an issue, why not work around it and copy things yourself to a spot of your own choosing? (such as the current dir: "file copy blah [[pwd]]") - the point I'm making is that starkits + VFS can do funny things, but you can always take over if you prefer. So yes, there are some unavoidables in playing nice with/for starkits, but the benefit of "wrap-and-go" is hard to overestimate. I routinely wrap things in the midst of active development, to the other side of the globe, to allow someone else to check something out. No testing, nothing. We often *afterwards* laugh, because we work on different platforms, and never even noticed. Maybe the lesson from your comments is that things need to be better documented. I'll gladly do so - am starting to do this more now, on the www.equi4.com website. ---- [Sexy Starkits] [Category Tclkit]