From: Daniel A. S. <st...@ic...> - 2002-10-17 02:27:56
|
Jim, On Thursday, Oct 17, 2002, at 11:50 Australia/Sydney, Jim Ingham wrote: > Humm, so maybe adding a tclMacOSXPkgSearch equivalent to the > tclMacPkgSearch, but looking down into Resources/Scripts would be > better? Then as long as the framework directories are in the > tcl_pkgPath, this should do what Steve wants. that sounds like the way to go, probably something needs to be added to tcl_findLibrary as well though to deal with Resources/Scripts (note that tcl_findLibrary currently doesn't work with packages found via tclMacPkgSearch either, I'm using a hack to get TclX to work on OS9). >> Anyway, I'm not sure this is really the right way to go, usually >> frameworks are for linking and tcl packages are for loading, a bundle >> structure seems more appropriate than a framework structure, no? > > Why do you say this? C-only Tcl packages (or mostly C ones) are not > that uncommon. Since the meat of these is a dylib, seems to me a > framework is the natural place to put them... We shouldn't force > people to use Frameworks, but we should make it possible. I see your point. One thing I don't like that much about the proposed scheme is that there is some confusion of where Tcl extensions should go: in Library/Tcl if they are built one way (TEA) and Library/Frameworks if they are built another way (PBX). It would probably be clearest to always check for a pkgIndex.tcl file in Resources/Scripts, regardless of whether we are in a .framework or not, I guess your tclMacOSXPkgSearch idea would do exactly that. > Fred didn't know much about Tcl, though... And we already had to move > the binary bits from being bundles to being dylibs, because bundles > weren't the right model for Extensions... If we are going to really > treat Tcl extensions as purely loadable bundles, then we should go > back to -bundle, and change tclLoadDyld.c to match. But I actually > don't think this is a good idea.. no, I agree, not a good idea indeed, if only for TEA support. Way too many things there assume that extensions are built in the same way as shared libraries > But this doesn't work for the @executable_path/../Frameworks, which we > should also support, right? @executable_path/../lib works but not @executable_path/../Frameworks >> >> For tclAE, I've used a project builder bundle target, with a >> pkgIndex.tcl file added at the toplevel that sources the standard >> pkgIndex.tcl in Contents/Resources (better would have been >> Contents/Resources/Scripts). This works very well and doesn't require >> any changes to Tcl. > > It seems confusing to me to have a bundle that doesn't have a library > built with -bundle, but rather with -dynamiclib. That should be a > .framework... except that much of the framework semantics are lost/not available when loading directly, e.g. versioning, subframeworks etc. All of these are only applicable if the linking is via dyld at startup (and maybe when using CFBundle APIs ?) >> However this again breaks the basic assumption that package loading >> looks for pkgIndex.tcl files on the auto_path, but at least all >> directories that are searched are present on the auto_path. > > It is pretty much analogous to looking in the TEXT resources for > libraries on the auto_path, however... That worked fine on classic > MacOS... except for tcl_findLibrary, plus every extension needed a handcrafted pkgIndex using source -rsrc :-( the latter is not going to be a problem on OSX of course >> >> Steve, what are the advantages to having your packages as frameworks >> over bundles? Do you need to link with other tcl packages as >> libraries? it might be better to stubify such extensions in that >> case, this is what e.g. incrTcl does. >> > > The System Overview isn't totally clear on this, but generally > .dylib's are supposed to live in .framework versioned bundles (or with > no structure at all, in some place like /usr/lib) and plugins & > pallets (usually built with -bundle) live in .bundle directories. > Dunno if we will ever want to use the versioning so that we have two > versions of the Itcl dylib in the framework, for instance, but having > the setup to do this might not be a bad idea... And the simplicity of > building a custom Wish that links directly to the framework extensions > & gets all the library paths from CFBundle is worth preserving... maybe it'd be worth exploring finding framework extensions via the CFBundle APIs instead of hardcoding the paths to the framework directories, that would bring automatic support for DYLD_FRAMEWORK_PATH and @executable_path/../Frameworks and maybe even versioning, not sure about that one. I guess that'd break the auto_path semantics too though. >> BTW, none of this was necessary for me to build TclXML, TclDOM and >> TclXSLT for the BI distro, and once Andreas' TEA2 move is complete >> they'll all build in a straightforward manner using standard build >> tools, is it really worth it adding another buildsystem that needs to >> be maintained separately? >> > > We shouldn't break the way you did it for the BI distro, but if an > extension author wants to use frameworks, we should allow him or her > to, right? ah no, I'm not saying we should disallow this, I was just asking what the advantage was of using PBX for an extension where there is a TEA buildsystem already in place. For something like TclAE/Tclapplescript/Tclcarbon where there are no existing makefiles, it certainly makes sense to provide an easy way to build via projectbuilder (and a framework target is probably indeed the easiest way). Cheers, Daniel -- ** Daniel A. Steffen ** "And now to something completely ** Dept. of Mathematics ** different" Monty Python ** Macquarie University ** <mailto:st...@ma...> ** NSW 2109 Australia ** <http://www.maths.mq.edu.au/~steffen/> |