wcf3 I've been working on my new AMD 64-bit system (with SuSE 9.2) and learned very quickly that the existing platform specific package loading I was using didn't handle 64-bit stuff at all well. That combined with my desire for a easier way of building platform specific Starpacks that didn't contain the extensions for the platforms not needed by the wrapped runtime...I worked out the following.
Observation: Some extensions (e.g. tile) depend on the windowing system in use (I'm assuming...). For example, tile might be compiled against X11 or against Aqua on MacOSX. The following code places all extensions for an architecture in one place which makes it impossible to support both Aqua and X11. Admittedly this is a bit of an edge case, but it might be good to append [tk windowingsystem] to the computed library name wcf3 Excellent idea...done!
Simply place the following pkgIndex.tcl file in your xxx.vfs/lib directory and place all platform specific extensions in directories such as xxx.vfs/lib/_platform_Darwin-ppc or xxx.vfs/lib/_platform_Linux-x86_64
# Extend the auto_path variable to include a platform specific directory
# This provides the for multi-platform Starkits very easily. When
# wrapping a starkit with a runtime binary, you can exclude unneeded
# platform specific extensions by add the -ignore option to the wrap
# command as such:
#
# tclkit sdx.kit wrap myapp.freebsd5 -runtime tclkit-freebsd5-x86 \
# -ignore _platform_Darwin-ppc -ignore _platform_Linux-x86 \
# -ignore _platform_Linux-x86_64 -ignore _platform_Windows-x86
#
# Platform directories are generally located in the lib directory of the
# .vfs and are named such as:
# _platform_Darwin-ppc
# _platform_Darwin-ppc_classic
# _platform_Darwin-ppc_aqua
# _platform_Darwin-ppc_x11_32
# _platform_FreeBSD-x86
# _platform_FreeBSD-x86_64
# _platform_Linux-x86_32
# _platform_Linux-x86_64
# _platform_SunOS-sparc
# _platform_SunOS-x86_32
# _platform_Windows-x86_32
#
# Platform directories will be appended to ::auto_path if they exist,
# in order from more specific to less specific. The order used starts
# with platform/windowingsystem/wordsize and progresses with
# platform/windowingsystem, platform/wordsize, and finishing with
# just platform. For instance:
# _platform_Linux-x86_x11_32
# _platform_Linux-x86_x11
# _platform_Linux-x86_32
# _platform_Linux-x86
#
# Created by Chuck Ferril (wcf3) 04/2005
#
# Modified by wcf3 05/2005 to include the windowing system as
# suggested by an unknown person on the wiki. Also allowed for
# combining multiple layers of platform specific paths and cleaned
# up the code a bit.
#
proc ::auto_path4platform { dir } {
rename ::auto_path4platform {}
# generate the platform path
set platform [file join $dir "_platform_[lindex $::tcl_platform(os) 0]-"]
switch -glob -- $::tcl_platform(machine) {
intel -
x86* -
i*86* { append platform "x86" }
"Power*" { append platform "ppc" }
sun4* { append platform "sparc" }
default { append platform "$::tcl_platform(machine)" }
}
# generate the windowing system portion
set windowingsystem ""
if { [info commands tk] != {} } {
set windowingsystem "_[tk windowingsystem]"
}
# generate the word size portion
set wordsize ""
if { [info exists ::tcl_platform(wordSize)] } {
set wordsize "_[expr {$::tcl_platform(wordSize) * 8}]"
}
# append paths to ::auto_path starting with more specific and running to less specific
foreach testdir [list "${platform}${windowingsystem}$wordsize" \
"${platform}$windowingsystem" \
"${platform}$wordsize" \
"$platform"] {
if { [file exists $testdir] && [lsearch -exact $::auto_path $testdir] == -1 } {
lappend ::auto_path $testdir
}
}
}
::auto_path4platform $dirLV Just curious, why prefix the directory with _platform_ ? Note, however, I'd love to see something like this added to sdx's default directory layout, generated with the qwrap/unwrap combination.
wcf3 So you can easily exclude it from other packages. My goal was to reverse the -ignore option, and make a '-platform FreeBSD-x86' option that would exclude anything except the _platform_FreeBSD-x86 directory. The _platform_ makes it really clear that it is a platform specific directory tree so that in the future it would just work when a _platform_MrCoffee-z80 shows up.
wcf3 2005-10-24 I thought it might be nice for me to include a sample Makefile I use on *nix that handles multiple platform wrapping. The starkit will include all platforms, while the starpacks will only have the platform it is wrapped for.
BASENAME = myApp
all: ${BASENAME}.kit ${BASENAME}.exe ${BASENAME}.linux64 ${BASENAME}.freebsd5
NOLINUX = -ignore _platform_Linux-x86
NOSUNOS = -ignore _platform_SunOS-x86 -ignore _platform_SunOS-sparc
NODARWIN = -ignore _platform_Darwin-ppc
NOFREEBSD = -ignore _platform_FreeBSD-x86
NOWINDOWS = -ignore _platform_Windows-x86
${BASENAME}.kit:
tclkit sdx.kit wrap $@
${BASENAME}.linux:
tclkit sdx.kit wrap $@ -runtime runtimes/tclkit-linux-x86 ${NOSUNOS} ${NODARWIN} ${NOFREEBSD} ${NOWINDOWS}
${BASENAME}.linux64:
tclkit sdx.kit wrap $@ -runtime runtimes/tclkit-linux-x86_64 ${NOSUNOS} ${NODARWIN} ${NOFREEBSD} ${NOWINDOWS}
${BASENAME}.freebsd4:
tclkit sdx.kit wrap $@ -runtime runtimes/tclkit-freebsd4-x86 ${NOLINUX} ${NOSUNOS} ${NODARWIN} ${NOWINDOWS}
${BASENAME}.freebsd5:
tclkit sdx.kit wrap $@ -runtime runtimes/tclkit-freebsd5-x86 ${NOLINUX} ${NOSUNOS} ${NODARWIN} ${NOWINDOWS}
${BASENAME}.exe:
tclkit sdx.kit wrap $@ -runtime runtimes/tclkit-win32.exe ${NOLINUX} ${NOSUNOS} ${NODARWIN} ${NOFREEBSD}JMN 2005-10-25 I think the idea of standard pathnames for binaries for these systems is great, but It'd be nice to keep it a little separate from the auto_path extension bit. i.e How about a function that just returns appropriate paths - so that it's more useful for using other package-loading systems such as Tcl 8.5+ module system?
wcf3 2005-10-25 That would be really nice (as this is a bit messy/ugly), but this just works with the existing tools, code base, and runtimes. I needed something now and this allows me to simply drag and drop any existing extension into a directory within the .vfs and have it work without having to edit any source. This is of real importance when you start to maintain a large set of libraries over time; I know, because I tried. Upgrading a set of libraries that support four platforms and require mods to the loading mechanism was a real pain and took a great deal of time.
That said; I'm all for a better way, especially if you can host the libraries on a server and have them pulled to a local cache as needed or updated. I've played with this a little, but am not yet happy my implementation.