normalized platform names
Bob Techentin
starkit. This is fun!
But I've also got some C++ executables that I run via 'exec'. It took
me just a little while to figure out that they cannot be executed from
within the starkit's VFS, but I think I've got that settled by keeping
them external to the starkit. That's OK because my customers want
access to the executables anyway.
But how should I set up the bin directory for multiple platforms?
There are _so_ many ways. I could just build a directory name out of
$tcl_platform() fields for "os" and "machine", which works ok for
"Linux-i686", but it gets messy with the space in "Windows NT-i686" or
the slash in "HP-UX-9000/785".
I see in Steve Landers' and Jean-Claude Wippler's "CriTcl - Beyond
Stubs and Compilers" paper that critcl has a [platform] command to
solve this problem. Their command generates nice reliable strings
like "Linux-x86" and "Solaris-sparc". It will still trip up on the
HP's penchant for slashes because it doesn't have a special case for
that hardware (yet).
But is there any "official" code for generating consistent and
reliable platform directory names from the ::tcl_platform values? I
didn't find any on the wiki or in the google archives. Should we put
one in tcllib? As a start, I would suggest using critcl's platform
command with an addition to catch oddball machine names.
proc platform {} {
global tcl_platform
set plat [lindex $tcl_platform(os) 0]
set mach $tcl_platform(machine)
switch -glob -- $mach {
sun4* { set mach sparc }
intel -
i*86* { set mach x86 }
"Power Macintosh" { set mach ppc }
9000* {set mach 9000}
}
set mach [regsub -all {[ /]} $mach "-"
return "$plat-$mach"
}
Bob
--
Bob Techentin techenti...@NOSPAMmayo.edu
Mayo Foundation (507) 538-5495
200 First St. SW FAX (507) 284-9171
Rochester MN, 55901 USA http://www.mayo.edu/sppdg/
Joe English
>But how should I set up the bin directory for multiple platforms?
>There are _so_ many ways. I could just build a directory name out of
>$tcl_platform() fields for "os" and "machine", which works ok for
>"Linux-i686", but it gets messy with the space in "Windows NT-i686" or
>the slash in "HP-UX-9000/785".
This is a really sticky problem. In general, some combination
of the $tcl_platform entries ought to be useful for determining
binary-compatibility equivalence classes, but *which*
combination is highly dependent on the OS. (To make things
even more complicated, binary compatibility is not even an
equivalence relation.)
Taking IRIX as an example: shared libraries compiled on
IRIX 6.x can generally be used on IRIX 6.y for any value
of y >= x, but not vice versa. Also, IRIX N.x can run
executables compiled under IRIX N-1.y (again, not vice
versa). Of course IRIX 6 also has 3 different ABIs
(o32, n32, and 64) which are mutually incompatible, and
four instruction set architectures (mips1 through mips4),
which are forward-compatible. The highest supported ISA
isn't directly stored anywhere in $tcl_platform, but it can
be determined by a lookup table on $tcl_platform(machine),
which is something like IP12, IP14, IP30, IP36, etc. on
SGIs.
(To handle the ISA differences on IRIX, I compile everything
with -n32 -mips3, even on mips4 machines, since there are very
few mips1 or mips2 hosts still living.)
And that's just IRIX. The best bet there is to check
$tcl_platform(osVersion).
Of course tcl_platform(osVersion) would be way too fine-grained a
check on Linux, since that includes a patch level (latest is 2.4.20)
and binary compatibility is typically preserved across major
releases. On Linux, $tcl_platform(machine) is probably the
best indicator, though that may be too fine-grained in the
case of i586 vs i686, and doesn't even reflect biggest Linux
binary compatibility issue, namely GLIBC releases, which
you can't determine at all from tcl_platform.
>I see in Steve Landers' and Jean-Claude Wippler's "CriTcl - Beyond
>Stubs and Compilers" paper that critcl has a [platform] command to
>solve this problem. Their command generates nice reliable strings
>like "Linux-x86" and "Solaris-sparc". It will still trip up on the
>HP's penchant for slashes because it doesn't have a special case for
>that hardware (yet).
>
>But is there any "official" code for generating consistent and
>reliable platform directory names from the ::tcl_platform values? I
>didn't find any on the wiki or in the google archives. Should we put
>one in tcllib? As a start, I would suggest using critcl's platform
>command with an addition to catch oddball machine names.
It would be a good idea to stick this up on the Wiki
and let it gestate for a while; hopefully people will
add details about platforms with which they are familiar.
> proc platform {} {
> global tcl_platform
> set plat [lindex $tcl_platform(os) 0]
> set mach $tcl_platform(machine)
> switch -glob -- $mach {
> sun4* { set mach sparc }
> intel -
> i*86* { set mach x86 }
> "Power Macintosh" { set mach ppc }
> 9000* {set mach 9000}
> }
> set mach [regsub -all {[ /]} $mach "-"
> return "$plat-$mach"
> }
--Joe English
lvi...@yahoo.com
According to Bob Techentin <techenti...@mayo.edu>:
:But how should I set up the bin directory for multiple platforms?
:There are _so_ many ways. I could just build a directory name out of
:$tcl_platform() fields for "os" and "machine", which works ok for
:"Linux-i686", but it gets messy with the space in "Windows NT-i686" or
:the slash in "HP-UX-9000/785".
Well, it gets messy when you consider that many times, operating system
releases on a platform can be incompatible, so that one needs to distingush
linux version 1 vs version 2 or whatever for instance (or Solaris 2.6 from
Solaris 9 - things like 64 bit support, etc.)
Some GNU autoconf based projects have a routine called config.guess.
The format it uses for platform is like this:
sparc-sun-solaris2.8
Hardware-Vendor-OperatingSystemVersion
--
Join us at the Tenth Annual Tcl/Tk Conference <URL: http://mini.net/tcl/6274 >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvi...@yahoo.com > <URL: http://www.purl.org/NET/lvirden/ >
Bob Techentin
>
>
> Well, it gets messy when you consider that many times, operating
system
> releases on a platform can be incompatible, so that one needs to
distingush
> linux version 1 vs version 2 or whatever for instance (or Solaris
2.6 from
> Solaris 9 - things like 64 bit support, etc.)
>
> Some GNU autoconf based projects have a routine called config.guess.
> The format it uses for platform is like this:
>
> sparc-sun-solaris2.8
>
> Hardware-Vendor-OperatingSystemVersion
I agree that this is a bit messy. On my platforms, I get these
strings from GNU's config.guess:
i686-pc-cygwin
i686-pc-linux-gnu
hppa2.0w-hp-hpux11.00
alphaev6-dec-osf4.0e
While these are probably close to cannonical, they are also probably
too detailed. I think it is reasonable to condense the intel
architectures into "x86" and the Alphas into "alpha" because they are
"binary compatible. But "hppa1.0" is really different from "hppa2.0".
It sounds like we will probably need an "expert" system, where some
code mirrors the opinions of the experts.
lvi...@yahoo.com
:code mirrors the opinions of the experts.
It also sounds as if we will be paralleling the 'expert system' work
being done in the config.guess script. Too bad we can't somehow
share information instead of reinventing the wheel.